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DRAFT  MILITARY  HANDBOOK  FOR 

MAINTENANCE  TASK  IDENTIFICATION  AND  ANALYSIS: 
ORGANIZATIONAL  AND  INTERMEDIATE  MAINTENANCE 

1.  SCOPE 

1.1  Scope  of  the  Handbook.  This  handbook  covers  the  development  of  maintenance 
task  identification  and  analysis  in  accordance  with  the  requirements  of  and  used 
in  conjunction  with  the  Draft  Military  Specification  for  Maintenance  Task  Identi¬ 
fication  and  Analysis,  AFHRL-TR-79-50.  The  Draft  Specification  defines  the 
requirements  for  content  and  format  of  Task  Analysis,  which  is  used  as  a  basis 
for  preparation  of  Organizational  and  Intermediate  Job  Performance  Aid  (JPA) 
manuals  and  other  types  of  Technical  Orders. 

Job  Performance  Aids  (JPAs)  are  manuals  that  provide  detailed,  step-by-step 
instructions.  Because  JPAs  are,  by  definition,  thorough  and  complete,  they 
require  a  detailed  task  analysis  phase  before  manual  development  can  begin. 

Two  of  the  major  types  of  JPAs,  Job  Guide  Manuals  and  Logic  Tree  Trouble¬ 
shooting  Aids,  are  referred  to  throughout  this  handbook  by  the  abbreviations 
JGM  and  LTTA,  respectively,  or  by  the  more  general  category,  JPAs,  Mainte¬ 
nance  Task  Identification  and  Analysis  is  also  referred  to  in  general  terms  as 
"task  analysis"  or  abbreviated  to  MTI&A  in  this  handbook  and  in  the  Draft 
Specification. 

Job  Guide  Manuals  (JGMs)  provide  instructions  for  fixed-procedure  tasks  such 
as  adjustment,  removal  and  installation,  and  repair.  The  instructions  are  pre¬ 
sented  in  a  step-by-step  format  and  are  supported  by  detailed  illustrations. 
LTTAs  provide  instructions  for  Checkout  and  Troubleshooting  tasks  in  a  detailed, 
step-by-step  format.  They  provide  the  technician  with  the  steps  to  follow  to 
check  out  the  system  and  to  isolate  malfunctions  to  replaceable  or  repairable 
units.  Both  iypes  of  JPAs  and  other  types  of  technical  manuals  cannot  be  effec¬ 
tively  prepared  unless  the  detailed  analytical  process  known  as  task  analysis 
provides  a  total  data  base  for  use  by  the  manual  developer. 


This  handbook  provides  explanation  of  the  planning  and  Implementation  of  the 
requirements  of  the  MTI&A  Draft  Specification.  Therefore,  the  user  of  this 
handbook  should  have  or  acquire  an  understanding  of  the  JPA  concept,  be  thor¬ 
oughly  familiar  with  the  requirements  of  the  MTI&A  Specification,  and  have  a 
copy  of  the  Draft  Specification  available  for  reference  while  using  this  handbook. 

1.2  Purpose  of  the  Handbook.  This  handbook  is  intended  to  assist  contractor  per¬ 
sonnel  who  are  required  to  perform  task  analyses  on  a  system  or  on  eqmpment. 
MTI&A  must  be  developed  in  accordance  with  the  requirements  of  the  Draft 
Specification  (AFHRL-TR-79-50),  The  handbook  provides  guidance  to  its  user, 
usually  referred  to  herein  as  the  task  analyst,  or  analyst,  with  many  relevant 
procedural  and  format  aids.  It  does  not  necessarily  enable  persons  who  have 
never  performed  maintenance  task  identification  and  analysis  to  do  an  effective 
job  just  by  following  the  procedures  outlined  in  the  handbook.  The  task  is  not 
that  simple.  Certain  important  qualifications  are  required  for  the  understanding 
of  the  technical  aspects  of  maintenance  analysis.  It  is  possible  to  develop  an 
MTI&A  that  meets  the  siq>erficial  criteria  of  format  and  identifiable  types  of  con¬ 
tent,  but  which  would  lead  to  ineffective  technical  manuals. 

To  guard  against  such  an  approach,  a  contractor  should  assign  only  task  analysts 
who  have  the  proper  technical  background  and  qualifications  and  should  require  a 
data,  config\iratlon  control,  and  quality  control  system  that  will  ensure  a  solid 
data  base  and  a  quality  analysis.  The  qualifications,  techniques,  and  systems 
that  have  been  found  to  be  suitable  are  suggested  in  this  handbook. 

The  handbook  is  intended  for  use  by  contractors  with  some  experience  in  prepar¬ 
ing  conventional  technical  data  or  maintenance  manuals  and  with  working  knowl¬ 
edge  of  DoD  maintenance  terminology,  policies,  and  systems.  However,  one 
should  not  assume  that  expertise  in  a^y  of  these  areas  is  all  that  is  required  to 
permit  effective  identification  and  analysis  of  maintenance  tasks.  Some  develop¬ 
ers  of  conventional  technical  literature  must  reprogram  themselves  to  the  disci¬ 
plined  and  careful  approach  that  task  analysis  requires.  Having  done  so,  a  good 
engineering  or  technical  writer  will  ordinarily  perform  task  analysis  effectively 
and  completely  and  appreciate  its  benefits  to  the  quality  and  real  usefulness  of 
the  final  product.  Subject  matter  experts,  such  as  engineers  or  technicians, 
educators,  and  behavioral  scientists  are  also  capable  of  effective  task  analysis. 

MTI&A  can  be  more  effectively  and  economically  performed  if  it  is  coordinated 
with  a  Logistic  Support  Analysis  (LSA)  program  as  explained  in  the  specification. 
Properly  implemented  and  kept  current,  the  detailed  data  base  provided  by  LSA 
Input  data  and  output  report  summaries  is  an  important  asset  to  MTI&A.  For 
that  reason,  this  handbook  discusses  LSA-based  MTI&A  separate^  (in  Section  5) 
from  MTI&A  without  an  LSA  base  (in  Section  6).  Many  MTI&A  analyses  and 
products  are  performed  differently  when  complete  LSA  data  are  available.  In 
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order  to  keep  both  sections  self  sufficient,  therefore,  some  redundancies  will  be 
found  between  the  sections.  In  actual  use,  the  analyst  should  decide  whether  the 
LSA  data  are  complete  and  available  for  use  and  then  follow  the  guidance  in 
Section  5.  If  it  is  not,  the  analyst  should  disregard  Section  5  and  follow  the 
guidance  in  Section  6. 

Throughout  the  handbook  and  the  specification,  the  process  of  analysis  is  dis¬ 
tinguished  from  the  products  of  that  analysis.  The  anafyst  must  first  perform 
the  research  and  study  involved  in  the  analysis  and  then  record  the  results  of 
that  analysis  in  the  form  of  analysis  products.  The  handbook  also  describes  all 
development  processes  as  though  they  are  to  be  performed  only  once,  from 
beginning  to  end,  and  in  neat  sequence.  In  practice,  however,  many  iterations 
and  revisions  of  steps  may  be  required  and  several  analysis  steps  will  be  in 
process  simultaneously.  Updating  is,  of  course,  a  recycling  process  that  can 
be  treated  as  separate  from  the  initial  development  process. 

1.3  Background.  The  development  of  JGMs,  LTTAs,  and  other  types  of  technical 
manuals  containing  detailed  procedures  requires  a  rational,  systematic  means  of 
first  identifying  the  job  tasks  and  then  determining  the  scope,  content,  method  of 
performance,  and  other  details  of  the  tasks.  MTI&A  provides  this  means  by 
defining  a  systematic  process  of  data  collection,  analysis,  and  decision  making. 
Essentially,  the  analysis  answers  these  questions: 

a.  What  tasks  are  required? 

b.  Which  should  be  included  in  a  JPA? 

c.  At  which  maintenance  level  are  they  performed? 

d.  What  are  the  preconditions? 

e.  What  support  equipment  is  needed? 

f.  What  instructions  must  be  provided  for  its  use? 

g.  What  are  the  most  efficient,  imderstandable  steps  for  the  technician  to 
follow  when  performing  a  troubleshooting  or  nontroxibleshooting  task? 

h.  What  follow-on  maintenance  is  needed? 

The  more  complete,  accurate,  and  understandable  the  task  analysis,  the  easier 
the  job  of  the  JPA  developer  and  the  more  effective  the  final  product,  the  JPA, 
or  technical  manual. 

The  validity  of  the  MTI&A,  and  therefore  of  the  subsequent  JPAs,  is  assured  by 
the  following  key  requirements  for  MTI&A  development: 

a.  Use  of  the  actual  equipment  in  representative  configiuration  for 
"hands-on"  analysis  and  validation  of  maintenance  tasks 
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b.  Early  identification  and  definition  of  the  user  population  and  its  informa¬ 
tion  needs 

c.  Use  of  the  same  logistics  data  base  and  analyses  that  are  used  for  other 
logistics  purposes,  assuring  commonality  and  eliminating  redundant 
effort 

d.  Early  and  continuing  evaluation  and  guidance  through  Contractor  quality 
assurance  (QA)  and  Government  reviews 

e.  Timely  update  to  accommodate  changes  to  equipment  or  software  and  to 
correct  errors 

f.  Thoroughness  of  the  effort  and  skills  and  experience  of  those  performing 
the  analysis. 

A  degree  of  analysis  has  always  been  performed  by  technical  writers  and  plan¬ 
ners  attempting  to  define  the  content  of  conventional  technical  manuals.  The 
difference  between  those  manuals  and  JPAs  or  other  advanced  forms,  however, 
is  that  a  much  more  thorough,  realistic  analysis  effort  is  needed  to  provide  a 
high  degree  of  assurance  that  all  components  and  significant  maintenance  tasks 
are  Identified  and  their  performance  requirements  established  at  an  early  stage 
of  development.  MTI&A  provides  this  assurance  by  making  use  of  system  analy¬ 
sis  techniques,  systematizing  and  formalizing  the  process,  and  recording  the 
results  in  a  consistent,  structured  fashion. 

The  analyses  are  recorded  or  documented  on  a  number  of  products  prepared 
the  analyst.  These  products  then  become  the  criteria  for  the  content,  structure, 
and  completeness  of  the  ultimate  maintenance  aid.  They  will  be  used  as  planning 
documents  and  source  data  during  development,  and  as  checks  on  their  complete¬ 
ness  later  on. 

MTI&A  may  be  applied  to  development  of  other  types  of  technical  manuals  as 
well  as  to  JPAs,  and  its  use  for  this  purpose  is  encouraged.  When  used  as  a 
basis  for  conventional  technical  manual  development,  file  major  difference  is  the 
degree  of  detail  required,  particularly  in  the  task  detail  analysis.  A  further  use 
of  MTI&A  is  as  a  tool  for  evaluating  existing  technical  manuals,  ascertaining 
that  all  needed  maintenance  tasks  have  been  covered  and  that  the  amount  and 
kinds  of  detail  are  appropriate  to  the  actual  user  population. 

The  intent  of  the  MTI&A  Specification  is  to  define  the  analyses  required  to  be 
performed  and  to  provide  guidelines  for  their  content,  preparation,  and  use. 

The  specific  details  and  methods  by  which  the  analyses  are  actually  developed 
are  not  so  important  as  the  effectiveness  and  thorou^ess  with  which  they  are 
carried  out  and  the  usefulness  of  the  final  results. 
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2.  APPLICABLE  DOCUMENTS 


2.1  Issues  of  Docuimntt.  Unless  specified  otherwise  in  the  contract,  the  following 
documents,  of  the  issue  in  effect  on  the  date  of  the  invitation  for  bids  or  request 
for  proposal,  form  a  part  of  this  handbook  to  the  extent  specified  herein: 

SPECIFICATIONS 


MILITARY 

MIL-M-38784A 

MIL-M-3880A  (USAF) 

MIL-M-83495  (USAF) 

AFHRL-TR-79-49 

AFHRL-TR-79-50 

MIL-I-45208A 

MIL-Q-9858A 

STANDARDS 

MIL-STD-863A 

MIL-STD- 1388-1  and  -2 
MIL-STD-785A 

MIL-STD-882A 


Manuals,  Technical:  General  Style  and 
Format  Requirements 

Manuals,  Technical:  Organizational 
Maintenance  Instructions 

Manuals,  Technical,  Organizational 
Maintenance  Manual  Set:  General 
Requirements  for  Preparation  of 

Manuals,  Technical:  Logic  Tree 
Troubleshooting  Aid  (LTTA) :  Organiza¬ 
tional  and  Intermediate  Maintenance 

Maintenance  Task  Identification  and 
Analysis:  Organizational  and  Intermedi¬ 
ate  Maintenance 

Inspection  l^stem  Requirements 
Quality  Proipram  Requirements 


Preparation  of  Wiring  Diagrams  and 
^stem  Schematic  Diagrams 

Logistic  Support  Analysis 

Reliability  Program  for  Itystems  and 
Eqxiipment  Development  and  Production 

^stem  Safety  Program  Requirements 


OTHER  DOCUMENTS 


AFR  36-1  Officer  Classification  Manual 

AFR  39-1  Airman  Classification  Manual 

(Government  Contractors  may  obtain  copies  of  the  above  documents  from  the 
American  National  Standards  Institute,  1430  Broadway,  New  York,  New  York 
10018.  Government  activities  may  obtain  copies  firom  (be  Commanding  Officer, 
Naval  Pti)licatlons  and  Forms  Center,  5801  Tabor  Avenue,  Philadelphia, 
Pennsylvania  19120. ) 

3.  DEFINITIONS 

3.1  Tf  rm  and  Definitions.  The  following  important  terms  and  definitions  are  used 
throu^out  this  handbook.  An  understanding  of  each  is  necessary  to  enable  die 
contractor  to  perform  effective  MTI&A. 

3. 1. 1  Action  tree.  A  branching  tree  diagram  for  a  fault  symptom  showing  the 
procedural  steps  required  to  isolate  each  fault  that  can  cause  that  symptom  to  a 
replaceable  component. 

3. 1.2  Analyst  (task).  An  individual  qualified  by  training  and  experience  to  per¬ 
form  the  task  analysis  process.  Personnel  assigned  this  position  (or  are  detailed 
to  assist  in  this  process)  should  have  an  understanding  of;  1)  analysis  techniques; 
2)  documentation  research  techniques;  and  3)  interview  tediniques.  An  analyst 
need  not  be  an  equipment  expert,  but  must  have  access  to  equipment  experts. 

3.1.3  Assembly.  A  number  of  parts  or  subassemblies,  or  combination.  Joined 
together  to  perform  a  specific  function  and  which  can  be  disassembled. 

(Examples:  Power  shovel-front,  fan  assembly,  audio  frequency  amplifier.) 
NOTE:  The  distinction  between  an  assembly  and  siiiassembly  is  determined  by 
the  individual  application.  An  assemb^  in  one  instance  may  be  a  subassembly 
in  another  where  it  forms  a  portion  of  an  assembly. 

3.1.4  .utomated  test  equipment  (ATE),  Automatically  sequenced  test  equipment 
used,  usually  at  intermediate  (shop)  level,  to  check  out  and  troubleshoot  8->fem- 
blies  of  a  system,  such  as  Line  Replaceable  Units  (LRUs). 

3. 1.5  Built-in  test  equipment  (BITE).  Test  equipment  built  into  a  system  that 
enables  it  to  perform  a  check  on  itself  automatically. 

3. 1.6  Failure  mode.  One  of  the  ways  in  which  a  component  can  Mil.  For 
example,  a  solenoid  can  have  three  failure  modes:  (1)  a  brdcen  coil,  (2)  broken 
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insulation,  or  (3)  restricted  mechanical  movement.  Each  of  the  three  failure 
modes  can  produce  a  different  fault  symptom. 


3.1.7  Fault  symptom.  An  observable  or  measurable  abnormal  indication,  oper¬ 
ation,  or  function  caused  a  fault  in  an  equipment  or  system.  Note  that  in  some 
^sterns,  for  aqy  given  system  state,  the  same  symptom  mi^  ^>pear  as  the 
result  of  any  one  of  many  possible  faults. 

3.1.8  Function.  A  group  of  functional  entities  and  fimctional  devices  or  circuit 
elements  that  work  together  to  accomplish  a  portion  of  a  system  or  an  equipment- 
assigned  objective.  For  example:  transmit,  receive,  display,  hoist,  train,  gen¬ 
erate  power,  and  control  actions. 

3.1.9  In-process  review.  A  review  of  an  MTI&A  project  conducted  at  critical 
points  for  the  purpose  of  evaluating  the  status  of  the  project,  accomplishing 
effective  coordination,  and  facilitating  proper  and  timely  decisions  required  dur¬ 
ing  the  task  analysis.  Also  includes  evaluation  of  work  in  progress  and  provision 
of  guidance. 

3.1.10  Intermediate  maintenance.  (See 'Maintenance  levels'). 

3. 1. 11  Job.  The  composite  of  duties  and  tasks  expected  of  an  individual  within 
a  particular  rating  or  specialty  and  at  a  particular  skill  level  or  rate. 

3. 1. 12  Job  guide  manual  (JGM).  A  specialized  technical  manual  containing 
illustrated,  highly  detailed,  step-by-step  procedures  for  the  accomplishment  of 
maintenance  tasks  other  than  checkout  and  troubleshooting. 

3.1.13  Job  performance  aid  (J PA).  Illustrated,  hi^ly  detailed,  step-by-step 
Instructions  for  the  performance  of  maintenance  tasks,  including  both  nontrouble¬ 
shooting  and  troubleshooting  tasks.  The  two  types  of  JPAs  (Job  Guide  Manuals 
and  Logic  Tree  Troubleshooting  Aids)  are  designed  to  provide,  in  one  place,  the 
information  that  a  technician  needs  to  do  all  of  the  job  tasks  on  a  system/ 
equipment. 

3.1.14  Logic  tree  trotd>leshooting  aid  (LTTA).  A  specialized  troubleshooting 
manual  based  on  logic  trees  and  c<xitaining  coordinated  sets  of  troubleshooting 
aids  such  as  checkout  procedures,  logic  trees,  fault  symptom  lists,  locator  dia¬ 
grams,  and  sometimes  supporting  reference  information  and  troubleshooting 
rationales. 

3.1.15  Maintainable.  Capable  of  being  adjusted,  aligned,  calibrated,  checked, 
tested,  trouble-isolated,  serviced,  repaired,  or  replaced. 
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3.1. 16  Maintenance  function.  A  group  of  maintenance  tasks  performed  on  a 
system  or  a  component  of  the  system.  Standard  maintenance  function  verbs  for 
use  in  the  Task  Identification  Matrix  (TIM)  are: 

a.  Adjust.  (1)  To  bring  to  a  specified  position  or  state;  (2)  to  bring  to  a 
more  satisfactory  state;  to  manipulate  controls,  levers,  linkages,  etc. ;  to  return 
equipment  fropi  an  out-of-tolerance  condition  to  an  in-tolerance  condition. 

b.  Align.  To  bring  into  line,  to  line  up;  to  bring  into  precise  adjustment, 
correct  relative  position,  or  coincidence. 

c.  Assemble.  To  fit  and  secure  together  the  several  parts  of;  to  make  or 
form  by  combining  parts. 

d.  Calibrate.  To  determine,  and  restore  if  necessary,  accuracy  by  special 
measurement  or  by  comparison  with  a  standard.  Usually  applied  to  test  and 
measurement  equipment  but  also  applies  to  other  highly  accurate  equipment. 

e.  Checkout.  To  perform  specified  operations  to  verify  operational  readi¬ 
ness  of  a  subcomponent,  component;  subsystem,  or  system. 

f.  Disassemble.  To  take  to  pieces;  to  take  apart  to  the  level  of  the  next 
smaller  unit  or  down  to  all  removable  parts. 

g.  Install.  (1)  To  perform  operations  necessary  to  properly  fit  an  equip¬ 
ment  unit  into  the  next  larger  assembly  or  system;  (2)  to  place  and  attach. 

h.  Operate.  To  control  equipment  in  order  to  accomplish  a  specific 
purpose. 

i.  Reassemble.  To  refit  and  secure  the  parts  of  the  item  after  they  have 
been  taken  apart. 

j.  Reinstall.  To  perform  operations  necessary  to  properly  refit  into  a 
system  or  subsystem,  an  item  that  was  previously  removed. 

k.  Remove.  (1)  To  perform  operations  necessary  to  take  an  equipment 
unit  out  of  the  next  larger  assembly  or  system;  (2)  to  take  off  or  eliminate; 

(3)  to  take  or  move  away. 

l.  Repair.  To  restore  an  equipment  item  to  operable  condition  by  means 
other  than  total  replacement. 

m.  Replace.  To  substitute  serviceable  equipment  for  malfunctioning,  worn 
out,  or  damaged  equipment. 
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n.  Service.  Operations  required  periodically  to  keep  an  item  in  proper 
operating  condition,  such  as  the  following: 

(1)  Balance.  To  equalize  in  weight,  height,  number,  or  proportion. 

(2)  Bleed.  To  extract  from  or  let  out  some  or  all  of  a  contained 
substance. 

(3)  Charge.  To  restore  die  active  materials  in  a  storage  battery  by 
the  passage  of  a  direct  current  through  in  the  opposite  direction 
to  that  of  the  discharge. 

(4)  Check.  (1)  To  confirm  or  establish  that  a  proper  condition  exists; 
to  ascertain  that  a  given  operation  produces  a  specified  result;  to 
examine  for  satisfactory  accuracy,  safety  or  performance;  to  con¬ 
firm  or  to  determine  measurements  by  use  of  visual  or  mechanical 
means;  (2)  to  perform  a  critical  visual  observation  or  check  for 
specific  conditions;  to  test  the  condition  of. 

(5)  Clean.  To  wash,  scrub,  or  apply  solvents  to;  remove  dirt,  cor¬ 
rosion,  or  grease. 

(6)  Coat.  To  cover  or  spread  with  a  finishing  protecting  layer. 

(7)  Drain.  To  draw  off  (liquid)  gradually  or  completely. 

(8)  Flush.  To  pour  liquid  over  or  through;  to  wash  out  with  a  rush  of 
liquid. 

(9)  Inspect.  To  perform  a  critical  visual  observation  or  check  for 
specific  conditions;  to  test  the  condition  of. 

(10)  Lvfcricate.  To  put  lubricant  on  specified  locations. 

(11)  Paint.  To  apply  color  or  pigment  (suspended  in  suitable  liquid)  to 
the  surface  of. 

(12)  Pressurize.  To  apply  pressure  within  by  filling  with  gas  or  liquid. 

(13)  Purge.  (1)  To  free  of  sediment  or  trapped  air  by  flushing  or  bleed¬ 
ing;  (2)  to  remove  fuel  or  fuel  vapors  from  engine  by  motoring 
engine  with  fuel  switch  off, 

(14)  Tune.  To  adjust  for  precise  functioning. 

o.  Test.  To  perform  specified  operations  to  verify  operational  readiness 
of  a  component,  subcomponent,  system,  or  subsystem. 

p.  Troubleshoot.  To  localize  and  isolate  the  source  of  a  malfunction  or 
breakdown. 
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3.1.17  Maintenance  levels.  The  three  basic  levels  of  maintenance  —  Organiza¬ 
tional,  Intermediate,  and  Depot  (not  covered  in  this  handbook)  —  into  which  all 
maintenance  activity  is  divided.  The  scope  of  maintenance  performed  within 
each  level  must  be  commensurate  with  the  personnel,  equipment,  technical  data, 
and  facilities  provided. 

a.  Organizational  maintenance.  Maintenance  which  is  the  responsibility  of, 
and  performed  by,  a  using  organization  on  its  assigned  equipment.  Its  phases 
normally  consist  of  inspecting,  servicing,  lubricating,  adjusting,  and  replacing 
of  parts,  assemblies,  and  subassemblies. 

b.  Intermediate  maintenance.  Maintenance  which  is  the  responsibility  of 
and  performed  by  designated  maintenance  activities  for  direct  support  and  gen¬ 
eral  sipport  of  using  organizations.  Its  phases  normally  consist  of  calibration, 
repair,  or  replacement  of  damaged  or  unserviceable  parts,  units  or  assemblies 
or  subassemblies;  the  emergency  manufacture  of  nonavailable  parts;  and  provid¬ 
ing  technical  assistance  to  using  organizations.  Intermediate  maintenance  is 
normally  accomplished  in  fixed  or  mobile  shops. 

3.1.18  Maintenance  step.  (See 'Task  step’) . 

3.1.19  Maintenance  task.  (See 'Task'). 

3.1.20  Maintenance  task  analysis,  (See 'Task  analysis'). 

3.1.21  Maintenance  task  identification.  (See  'Task  identification'). 

3.1.22  MTI&A  products.  The  recorded  results  of  Maintenance  Task  Identifica¬ 
tion  and  Analysis,  Includes;  Task  Identification  Matrix  (TIM)  or  Expanded  TIM 
(optional);  Definitized  User  Profile;  Level  of  Detail  Guide;  Support  Equipment 
Guide;  Task  Analysis  Worksheets;  Checkout  Summary;  Fault  l^ymptom  List; 
Action  Trees;  and  Task  Identification  Summaries  (optional). 

3.1.23  Part.  One  piece,  or  two  or  more  pieces  joined  together  which  are  not 
normally  subject  to  disassembly  without  destruction  of  designed  use. 

3.1.24  Performance  parameters.  Range  of  acceptable  values  for  a  system  or 
equipment  function  which,  when  measured  or  observed.  Indicate  satisfactory 
operation. 

3.1.25  Skill.  The  mastery  of,  or  proficiency  in,  a  technique.  Skills  involve 
physical  or  manipulative  activities.  They  often  require  knowledge  for  their 
execution.  All  skills  are  actions  having  special  requirements  for  speed,  accu¬ 
racy,  or  coordination. 
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3.1.26  Skill  level.  The  type  and  degree  of  skill  representing  the  extent  of  quali¬ 
fication  within  the  total  Air  Force  Specialty  Code  (AFSC).  It  reflects  the  skills 
typically  required  for  successful  performance  at  the  grade  with  which  the  skill 
level  is  associated. 

3. 1.27  Subassembly.  Two  or  more  parts  which  form  a  portion  of  an  assembly 
or  a  unit  replaceable  as  a  whole,  but  having  a  part  or  parts  which  are  individually 
replaceable. 

3.1.28  Subsystem.  A  major  functional  subassembly  or  grouping  of  items  of 
equipment  which  is  essential  to  the  operational  completeness  of  a  system. 

3.1.29  Subtask.  Any  group  of  related  behaviors  which  fulfills  a  limited  purpose 
within  a  task.  For  example,  "open  access  doors"  or  "set  i4>  test  equipment" 
may  be  subtasks  within  an  inspection  or  checkout  task. 

3.1.30  Support  and  test  equipment  (SE).  Referred  to  as  'support  equipment'  in 
this  handbook.  One  of  the  nine  principal  elements  of  Integrated  Logistics  Sup¬ 
port  (ILS).  Consists  of  tools,  metrology  and  calibration  equipment,  performance 
monitoring  and  fault  isolation  equipment,  maintenance  stands  and  handling  de¬ 
vices  required  to  support  the  operation  and  maintenance  of  systems.  Items  are 
categorized  as  peculiar  (to  the  system  under  development)  and  common  (com¬ 
mercially  available  or  currently  in  the  defense  inventory).  Includes  equipment 
categorized  as  Ground  Support  Equipment  (GSE)  or  Aerospace  Ground  Equipment 
(AGE). 

3.1.31  Symptom.  (See 'Fault  symptom'). 

3.1.32  System/equipment.  The  item  under  analysis,  be  it  a  complete  system 
or  any  portion  thereof  being  procured. 

3.1.33  Target  population.  (See 'User  population') . 

3.1.34  Task.  A  set  of  steps  describing  a  complete  start-to-finish,  step-by- 
step  maintenance  action. 

3.1.35  Task  analysis.  Also  referred  to  as  Maintenance  Task  Analysis.  A 
systematic  procedure  for  analyzing  an  identified  maintenance  task  to  determine 
what  the  task  consists  of,  what  is  needed  to  perform  it,  and  how  it  should  be 
performed.  Includes  defining  the  user  population,  support  equipment  require¬ 
ments,  and  level  of  detail  required.  The  recorded  results  of  task  analyses  are 
the  basis  for  development  of  Job  Guide  Manuals  and  Logic  Tree  Troubleshooting 
Aids. 
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3.1.36  Task  identification.  Also  referred  to  as  Maintenance  Task  Identification. 
The  ascertainment  and  itemization  of  the  troubleshooting  and  nontroubleshooting 
tasks  required  to  maintain  a  system/equipment  at  the  organizational  and  inter¬ 
mediate  levels. 

3.1.37  Task  step.  The  single,  smallest  logically  definable  maintenance  action, 
such  as  setting  a  switch  to  the  OFF  position.  Generally,  a  step  is  comprised  of 
one  action  but  in  certain  cases  may  be  a  series  of  identical  actions,  such  as 
removing  seven  bolts. 

3.1.38  Troubleshooting.  The  process  of  detection,  diagnosis  and  isolation  of 
equipment  malfunctions  for  repair. 

3.1.39.  User  population.  Also  referred  to  as  Target  Population.  Representa¬ 
tive  members  of  the  using  commands,  organizations  or  units  for  whom  the  Job 
Performance  Aids  will  be  developed,  and  therefore  at  whom  the  MTI&A  is  aimed. 

3.1.40  Validation.  The  process  by  which  the  contractor  ensures  the  adequacy, 
accuracy,  and  completeness  of  the  MTI&A  and  their  suitability  for  the  intended 
purpose.  Procedural  data  are  validated  by  actual  performance  on  the  subject 
system/equipment,  while  nonprocedural  data  are  validated  by  such  methods  as 
comparison  with  source  data,  analysis  by  experts,  etc, 

3.1.41  Verification.  The  process  by  which  the  Government  assures  the  accu¬ 
racy,  adequacy,  completeness  and  suitability  of  the  MTI&A  products  and  their 
conformance  with  contract  and  specification  requirements.  This  includes 
Government  action  to  assure  proper  validation  by  the  contractor,  actual  com¬ 
parison  with  the  hardware,  and  other  suitable  actions. 

4.  GENERAL  DESCRIPTION  AND  PLANNING  OF  TASK  ANALYSIS 

4.1  Overview  of  the  MTI&A  Process.  Figure  1  shows  the  six  basic  analyses,  the 
products  that  are  required  to  document  each,  and  their  interrelationships.  Some 
of  the  analyses  can  be  prepared  independently  of  others,  some  require  prior 
completion  of  other  analyses,  and  the  preparation  of  some  analyses  may  overlap. 
For  Job  Guide  Manual  (JGM)  type  of  JPAs,  which  cover  only  fixed  procedure 
tasks,  such  as  adjustment,  alignment,  disassembly,  all  of  the  analyses  except 
the  troubleshooting  analyses  are  performed.  For  LTTAs  or  other  manuals  that 
will  provide  detailed  trouble  diagnosis  procedures,  the  troubleshooting  analyses 
are  added  to  determine  the  number  and  content  of  fault  diagnosis  procedures. 

The  first  step  in  task  analysis  is  the  development  of  a  Task  Analysis  Plan,  which 
describes  the  planned  use  of  resources,  equipment,  subject  matter  experts,  as 
well  as  schedules  and  quality  control. 


FIGURE  1.  Detailed  MTI&A  process. 


Task  identification  is  the  first  analysis  to  be  performed.  Each  task  identified  at 
this  stage  as  a  candidate  for  maintenance  coverage  and  possible  inclusion  in  the 
JPAs  is  subsequently  examined  in  the  task  detail  analysis  and  if  appropriate,  in 
the  troubleshooting  analysis.  The  task  identification  is  based  i4x>n  an  equipment 
breakdown,  a  listing  of  maintenance  functions  applicable  to  the  subject  system, 
and  the  maintenance  concept.  The  Task  Identification  Matrix  (TIM)  is  a  matrix 
of  all  equipment  and  items  maintainable  at  the  maintenance  levels  (Organizational 
or  Intermediate)  under  consideration.  As  each  task  is  identified,  it  is  recorded 
on  the  TIM,  which  is  the  product  of  the  task  identification  process.  Cell  entries 
in  the  matrix  identify  all  of  the  possibilities  for  tasks  and  indicate  the  level  of 
maintenance  at  which  each  task  is  performed.  Although  it  is  extremely  impor¬ 
tant  in  completing  MTI&A  to  do  further  analysis  of  each  identified  task,  task 
identification  can  be  developed  independently  for  several  special  applications. 

For  example,  a  comprehensive  TIM  can  be  an  important  aid  in  developing  or 
evaluating  the  completeness  of  maintenance  coverage  in  conventional  technical 
manuals. 

Next,  the  User  Analysis  carefully  describes  the  expected  user  of  the  maintenance 
aid  (i. e. ,  the  Job  Performance  Aid  or  technical  manual).  Before  the  identified 
tasks  can  be  further  detailed,  it  is  essential  to  define  the  abilities,  knowledge, 
and  skills  of  the  target  user  population  for  whom  the  JPA,  and  therefore  the  task 
analysis,  will  be  prepared.  The  Government  should  provide  a  Preliminary  User 
Profile,  which  is  further  refined  by  the  developer  based  on  the  technical  needs 
of  the  system.  Eventually,  the  final  product  of  user  analysis,  called  a  Defini- 
tized  User  Profile,  is  produced.  It  is  used  as  a  reference  when  conducting  the 
level  of  detail  analysis,  the  support  equipment  analysis,  and  the  task  detail  anal¬ 
ysis.  Furthermore,  it  is  a  definitive  document  used  by  developers  when  writing 
procedures.  The  user  analysis  can  be  performed  concurrently  with  task  identi¬ 
fication,  as  they  are  not  interdependent. 

The  Support  Equipment  Analysis  is  performed  to  identify  all  test  equipment, 
special  tools,  and  special  ground  support  equipment  required  during  performance 
of  the  identified  maintenance  tasks.  It  determines  the  assumptions  to  be  made 
about  the  user's  abilify  concerning  the  required  tools  and  equipment  and,  based 
on  these  assumptions,  develops  standard  statements  to  be  used  when  writing  task 
steps  involving  the  use  of  the  equipment.  The  product  of  this  analysis  is  called 
a  Siqjport  Equipment  Guide,  and  the  User  Analysis  must  be  completed  before  it 
can  be  finalized. 

Given  the  skills,  knowledge,  and  abilities  of  the  target  users  as  defined  in  the 
Definitized  User  Profile,  a  Level  of  Detail  Analysis  is  performed  to  determine 
the  kinds  and  amount  of  detailed  information  needed  by  these  users  to  success¬ 
fully  perform  the  required  tasks.  The  product  of  this  anafysis  is  called  a  Level 
of  Detail  Guide.  It  contains  guidelines,  or  rules,  to  be  used  in  writing  Task 
Analysis  Worksheets  and  task  steps  (other  than  those  involved  in  use  of  support 
equipment)  for  both  nontroubleshooting  and  troubleshooting  tasks. 


Each  nontroubleshooting  task  that  was  identified  in  the  TIM  as  needing  a  proce¬ 
dure  for  inclusion  in  a  Job  Guide  Manual  is  subjected  to  a  searching  analysis, 
called  a  Task  Detail  Analysis,  to  answer  the  questions  posed  earlier  about  each 
identified  task.  The  product  of  this  analysis  is  a  set  of  Task  Analysis  Work¬ 
sheets  that  provide  the  basis  for  the  corresponding  procedure  in  the  subsequent 
JGM.  The  worksheets  provide  data  on  equipment  condition  and  performance  pre¬ 
requisites;  support  equipment  and  materials  needed,  safety  precautions,  person¬ 
nel  requirements,  basic  task  steps  with  performance  standards,  and  follow-on 
tasks.  Essential  inputs  to  this  analysis  are  provided  by  the  User  Analysis,  Level 
of  Detail  Analysis,  and  the  Support  Equipment  Analysis. 

In  troubleshooting  task  analysis,  the  task  analyst  must  literally  solve  all  of  the 
troubleshooting  problems  that  the  maintenance  technician  is  likely  to  encounter. 
Task  analysis  for  troubleshooting  consists  of  Performance  Analysis  and  Failure 
Mode  and  Fault  Symptom  Analysis,  which  are  documented  in  the  form  of  Action 
Trees  and  result  in  the  description  of  branched-procedure  tasks  for  use  by  the 
LTTA  developer.  Each  hardware  item  with  checkout/troubleshoot  task  entry 
identified  in  the  TIM  for  inclusion  in  a  LTTA  is  subjected  to  a  troubleshooting 
analysis.  The  objective  of  this  analysis  is  to  determine  how  many  different  ways 
that  component  can  fail  (its  failure  modes)  and  how  many  measurable  perform¬ 
ance  parameters  of  the  system  its  failure  modes  can  affect. 

Performance  Analysis  identifies  functional  characteristics  of  the  system,  in 
terms  that  can  be  checked  and  these  checks  are  developed  to  see  if  the  system 
functions  are  being  performed  properly.  This  analysis  is  recorded  on  a  Check¬ 
out  Summary. 

By  analyzing  each  failure  mode  and  the  symptom(s)  each  can  cause  (its  fault 
symptoms),  the  analyst  can  determine  how  each  normal,  performance  parame¬ 
ter  can  be  measured  to  show  whether  the  component  is  failing  and  the  elements 
that  can  cause  the  failure.  This  phase  of  analysis  is  known  as  Failure  Mode 
and  Fault  Symptom  Analysis.  From  this  analysis,  a  Checkout  Summary  and  a 
Fault  Symptom  List  are  produced.  The  Checkout  Summary,  when  considered 
along  with  the  check/troubleshoot  tasks  identified  in  the  TIM,  establishes  the 
scope  of  the  LTTA  checkout.  The  fault  symptom  list  defines  the  fault  symptoms 
that  must  be  addressed  during  development  of  the  troubleshooting  Logic  Trees 
in  the  LTTA.  It  also  provides  the  LTTA  preparer  with  the  list  of  systems  and 
imits  that  must  be  tested  and  considered  for  corrective  action  within  the  Logic 
Tree  guidelines. 

Action  Trees  are  the  final  product  of  troubleshooting  task  analysis  and  are  the 
basis  for  later  development  of  the  LTTA.  There  is  an  action  tree  (AT)  for  each 
fault  symptom  in  the  fault  symptom  list.  An  AT  is  a  branching  tree  trouble 
diagnosis  outline  depicting  the  most  orderly  approach  for  diagnosiT^  the  fault 
presented  by  the  fault  symptom. 
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The  troubleshooting  analysis  also  includes  data  resulting  from  considerations  of 
hazardous  components  such  as  energy  sources,  fuels,  propellants,  explosives, 
and  pressure  systems  and  reliability  analysis  data. 

The  results  of  MTI&A  are  recorded  in  various  forms  known  as  Task  Analysis 
Products.  The  specification  (AFHRL-TR-79-50)  calls  out  a  number  of  sample 
forms  such  as  the  TIM  form  and  Task  Analysis  Worksheet  form  that  are  used  in 
collecting  and  storing  data  and  in  presenting  MTI&A  intermediate  products  for 
review  by  various  subject  matter  experts  and  the  Acquisition  agency.  As  ex¬ 
plained,  it  is  not  as  important  to  use  the  exact  form  or  format  provided  in  the 
specification  as  it  is  to  supply  all  of  the  data  required  by  the  specification. 

Other  formats  for  the  data  required  may  be  permitted  by  the  Acquisition  agency 
if  they  are  clear,  easy  to  understand,  easy  to  update,  and  easy  for  a  JPA  devel¬ 
oper  to  use. 

4.2  Fundamentals  of  Task  Analysis.  Keys  to  establishing  an  effective  MTI&A  capa¬ 
bility  or  evaluating  an  organization’s  ability  to  become  effective  are 

a.  Understanding  the  MTI&A  concept  and  believing  in  its  importance 

b.  Careful  selection  of  lead  task  analyst  personnel 

c.  Separation  of  the  MTI&A  function  from  normal  documentation  or  publi¬ 
cations  work 

d.  Careful  planning  and  scheduling 

e.  Ensuring  a  firm  technical  support  function  for  data  input  and  dedicated 
subject  matter  experts 

f.  Proper  application  of  the  techniques  outlined  in  this  handbook, 

A  major  contribution  of  MTI&A  resides  in  its  rational,  systematic,  analytic 
foundation  for  developing  effective  JPAs  or  manuals.  Only  complete,  accurate, 
and  imderstandable  task  analyses  can  ensure  JPAs  that  are  totally  reliable  for 
the  maintenance  technicians  in  the  field. 

MTI&A  procedures  focus  the  attention  of  the  task  analyst  on  small  steps.  The 
analyst  must  identify  and  describe  what  the  technician  perceives  and  what  the 
technician  should  do.  The  analyst  must  communicate  optimal  work  tasks  and  a 
set  of  steps  that  will  permit  the  technician  to  achieve  task  goals. 

The  difficulties  in  doing  task  analysis  are  not  in  following  the  prescribed  pro¬ 
cedures  —  they  are  in  the  resistance  the  task  analyst  encounters  in  gaining 
access  to  equipment,  in  getting  permission  to  have  equipment  disassembled,  in 
requiring  detailed  graphics,  and  in  making  detailed  descriptions  when  grosser 
descriptions  might  superficially  appear  to  be  adequate.  The  more  completely 


the  analyst  imderstands  the  user's  job,  what  the  analyst  is  told,  and  what  the 
analyst  observes,  the  better  is  the  analysis.  The  analyst  will  find  that  most 
tasks  can  be  performed  in  several  ways  and  that  much  task-relevant  information 
can  be  interpreted  in  more  than  one  way.  However,  the  analyst  must  constantly 
concentrate  on  determining  the  methods  that  will  work  best  in  the  field  and  on 
communicating  those  methods  in  sufficient  detail  to  guarantee  effective  task 
performance.  The  difficulties  that  a  task  analyst  encounters  and  solves  in  this 
process  are  the  very  difficulties  that  technicians  in  the  field  would  encounter  and 
would  have  to  solve  many  times  over  if  the  task  analyst  had  not  done  it  once  and 
produced  a  maintenance  aid  designed  to  avoid  those  problems. 

The  process  of  troubleshooting  task  analysis  is  largely  a  matter  of  defining  and 
designing  the  diagnostic  tasks  and  is  a  research  and  organizing  effort  rather  than 
a  writing  effort. 

This  is  true  even  when  one  of  the  data  sources  is  existing  conventional  technical 
manuals,  since  they  may  not  contain  much  of  the  information  required  for  an 
effective  MTI&A.  When  analyzing  some  technical  manuals,  the  task  analysts 
may  find  that  they  are  not  based  on  the  user's  needs  in  performed  tasks,  but  on 
what  engineering  data  existed.  They  may  reflect,  for  example,  in  testing  pro¬ 
cedures  ,  test  equipment  that  is  not  available  to  the  field  technician  or  that  does 
not  address  fault  diagnosis  in  depth. 

Conventional  technical  manuals  are  frequently  directed  to  an  audience  presumed 
to  be  generally  technically  knowledgeable  and  more  familiar  with  the  subject 
equipment  than  is  presumed  in  the  case  of  the  ty^pical  JPA  user.  Furthermore, 
the  major  emphasis  of  many  conventional  technical  manuals  is  on  description  of 
the  subject  equipment  rather  than  on  instructions  for  the  tasks  the  user  must 
perform.  Task  descriptive  information  found  in  the  technical  manuals  is  often 
inadequate,  and  the  procedural  data  that  does  exist  must  be  modified  to  serve  the 
needs  of  the  prospective  users.  Task  analysts  should  consider  existing  techni¬ 
cal  manuals  as  no  more  than  a  suspect  data  source  in  the  MTI&A  process  — 
until  the  manuals  prove  themselves  to  be  otherwise.  The  analyst  must  rely  on 
direct  interaction  with  the  equipment  itself  and  must  assume  the  role  and  prob¬ 
lems  of  the  user,  by  direct  observation  of  hands-on  task  performance,  and  by 
interviews  with  task  performers. 

Now  that  some  of  the  pitfalls  and  problems  of  the  task  analyst  and  some  tech¬ 
niques  ha ve^ been  identified,  guidelines  can  be  provided  for  selecting  a  candidate 
for  the  task  analyst  function. 

4.3  Staffing  for  Task  Analyws.  The  contractor  must  consider  the  complexities  of 
MTI&A  and  perceive  the  kind  of  person  who  will  be  most  effective  as  a  resource¬ 
ful,  penetrating  researcher  and  who  will  examine  all  sides  of  a  maintenance 
problem  before  deciding  on  the  best  approach.  It  is  unlikely,  for  example,  that 


manual  writers  will  succeed  at  task  analysis  if  they  are  usually  content  to  "edit" 
the  work  of  others  without  ensuring  its  technical  integrity  and  completeness.  The 
function  requires  someone  who  will  test  each  data  input  for  appropriateness,  cur¬ 
rency,  and  completeness  before  using  it.  Of  course,  many  technical  writers  can 
perform  effectively  in  MTI&A;  but  others  with  years  of  technical  manual  develop¬ 
ment  experience  may  not  possess  the  interest  or  understanding  to  do  it  well. 
During  the  MTI&A  phase,  the  function  should  be  performed  by  an  analyst,  not  a 
writer.  In  the  MTI&A,  there  is  little  writing  ability  required  and  if  a  technical 
writer  is  assigned  to  do  the  job,  all  must  understand  that  the  technical  writer 
functions  as  an  analyst  during  that  phase,  even  though  the  technical  writer  may 
later  function  as  a  writer  and  utilize  MTI&A  products  to  develop  JPAs.  The 
distinction  is  important  because  altogether  different  talents  are  required  for 
task  analysis  than  for  communicating  procedural  ideas  to  a  reader  (the  job  of  a 
writer). 

4.3. 1  Task  Analyst  Qualifications.  An  MTI&A  staff  can  be  comprised  of  ana¬ 
lysts  with  various  technical  or  research  experience.  Some  developers  find  that 
creative  technical  writers  do  fine  task  analysis;  others  use  subject  matter 
experts,  such  as  engineers  or  technicians,  and  still  other  analysts  come  from 
backgrounds  and  professions  such  as  educators,  behavioral  scientists,  etc.  In 
any  case,  qualifications  can  vary,  and  as  a  result,  the  kind  of  person  required 
is  described,  rather  than  a  peculiar  discipline  or  job  title. 

The  preparation  of  maintenance  task  analyses  requires  persons  who  possess 
most  of  the  following: 

a.  Stilled  in  understanding  and  identifying  behaviors  with  which  technicians 
can  satisfactorily  perform  maintenance  tasks 

b.  Able  to  identify  critical  discriminations,  decisions,  contingencies,  and 
responses  required  of  the  technician,  and  document  this  information  in 
the  form  of  Instructions  which  can  be  followed  with  a  minimum  of  error 

c.  Familiar  with  the  characteristics  of  users  of  the  instructions  so  that 
they  can  limit  tasks  to  those  behaviors  which  are  within  the  users' 
capabilities 

d.  Familiar  with  electronic  and  mechanical  systems,  their  technical 
language,  and  principles 

e.  Resourceful  in  ferreting  out  the  data  required  by  task  analyses  —  data 
which  may  exist  in  a  wide  variety  of  forms  and  locations 

f.  Able  to  develop  tasks  when  documentary  data  about  tasks  do  not  exist 

g.  Familiar  with  analysis  techniques,  documentation  research  techniques, 
and  interview  techniques. 


4.3.2  Lead  Analyst.  Ideally,  the  MTI&A  staff  should  be  led  by  someone  with  at 
least  the  equivalent  of  a  Bachelor's  degree  in  some  field  of  science  or  applied 
psychology,  such  as  in  electronic  engineering,  human  engineering,  or  science 
education.  In  addition,  this  person  should  have  some  working  experience  in 
operation  or  maintenance  of  technical  devices,  such  as  those  possessed  by  a 
technician.  The  preparation  of  most  JPA  packages  will  require  more  than  one 
task  analyst  to  handle  the  large  amounts  of  data  and  it  is  advisable  for  at  least 
one  of  these  persons  to  have  performed  task  analyses  for  other  systems. 

Realistically,  all  task  analysts  cannot  possess  all  of  these  attributes  and  the  Lead 
Task  Analyst  can  be  supported  assistants  with  the  following  qualifications: 

4.3.3  Assistant  Task  Analyst.  Assistants  should  have: 

a.  At  least  two  years  of  college  and/or  completion  of  military  or  industrial 
tech  schools 

b.  At  least  one  year  of  experience  in  behavioral  task  analysis 

c.  Experience  with  electronic  and  mechanical  systems  and  some  exhibited 
skill  in  handling  tools  and  performing  technical  procedures 

d.  Experience  (over  two  years)  as  an  engineering  writer,  publications 
engineer,  or  technical  writer  who  has  been  responsible  for  developing 
procedural  data  without  benefit  of  existing  written  inputs. 

4.4  Task  Analysis  Planning.  An  effective  MTI&A  program  must  begin  with  a  defini¬ 
tive  plan  for  use  of  resources,  data,  hardware,  and  scheduling.  The  Task 
Analysis  Plan  is  a  plaiming  and  control  docionent  that  specifies  the  requirements 
necessary  to  effect  a  logical  approach,  organization  and  implementation  of  the 
process.  The  plan  is  the  responsibility  of  the  task  analysis  supervisor.  It 
must  delineate  what  is  to  be  done,  how  it  is  to  be  done,  and  establish  milestones 
to  be  applied  in  the  conduct  of  the  analysis.  The  plan  must  be  periodically  re¬ 
viewed  to  ensure  that  it  is  iq)  to  date  with  the  system  design  situation  and  reflects 
the  latest  maintenance  concepts. 

4.4. 1  Task  Analysis  Plan.  The  Task  Analysis  Plan  must  be  developed  to  reflect 
the  contract  requirements  for  maintenance,  to  explain  the  developer's  resources 
and  schedule,  and  to  comply  with  the  specification  for  MTI&A.  It  should  deline¬ 
ate  the  contractor's  plans  for  performing  the  MTI&A  and  for  ensuring  its  quali^. 
The  developer  should  discuss  in  the  plan,  each  type  of  analysis  to  be  performed 
and  the  product  of  each  analysis.  Included  should  be  the  methods,  procedures, 
and  data  sources  to  be  used,  the  equipment  plan,  the  procedures  for  coordinating 
the  MTI&A  development  with  the  developer's  Logistic  Support  Analysis  (LSA  or 
ILS)  function,  qualifications  of  assigned  analysis  personnel,  the  Quality  Assur¬ 
ance  Plan,  and  schedules  for  MTI&A  development,  review,  and  delivery. 
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The  plan  and  the  program  it  defines  should  assure  the  government  that  the  MTI&A 
will  be  well  organized,  capably  staffed,  technically  accurate  and  complete  in  all 
respects,  and  in  compliance  with  the  specifications.  The  plan  should  include  an 
organizational  flow  diagram  showii^  the  contractor's  understanding  of  the  rela¬ 
tionship  of  the  task  analysis  function  to  other  contract  data  and  hardware  require¬ 
ments,  especially  with  LSA  functions,  and  sample  forms  indicating  the  methods 
the  contractor  will  use  and  produce  in  the  MTI&A  efforts. 

4. 4. 1. 1  Initial  Planning.  The  contractor's  plan  shall  discuss  the  planning  that 
will  take  place  Immediately  after  contract  award  and  describe  and  include 
samples  of  all  development  and  quality  control  forms  with  which  MTI&A  will  be 
developed  and  monitored  for  quality  control  and  schedule  compliance. 

4.4. 1.2  Technical  Review.  The  contractor  shall  describe  in  the  plan  the  meth¬ 
ods  and  personnel  to  be  used  to  ensure  the  technical  accuracy  of  each  step  in 
task  development.  Describe  the  frequency  and  depth  of  technical  reviews  and 
the  technical  knowledge  of  the  personnel  who  will  conduct  the  reviews.  The  con¬ 
tractor  shall  also  explain  scheduling  of  the  technical  reviewer's  quality  monitor¬ 
ing  so  that  it  can  effectively  coincide  with  government  in-process  reviews  and 
validation. 

4.4. 1.3  Control  of  Subcontractor's  Task  Analysis.  The  contractor  shall  describe 
in  this  section  the  methods  to  be  used  for  ensuring  that  contract  and  quality  con¬ 
trol  requirements  will  be  invoked  on  subcontractors  that  supply  equipment  or 
services,  or  are  otherwise  involved  in  the  MTI&A  development. 

4.4. 1.4  In-Process  Review.  Validation,  and  Verification.  The  plan  shall  des¬ 
cribe  the  system  to  be  employed  to  inspect,  validate,  and  correct  task  analysis 
products.  The  plan  must  demonstrate  that  cognizant  contractor  personnel  under¬ 
stand  the  requirements  of  specification  paragraphs  4.2,  Contractor  Inspection, 
4.6,  Validation,  4.7.1,  In-Process  Review,  and  4. 7.2,  Verification.  It  should 
also  explain  the  process  and  scheduling  of  re-review,  re-validation,  or  re¬ 
verification  of  any  incorrect  or  inappropriate  data  found  during  these  checks  of 
the  task  analysis  products. 

4. 4. 1.5  Changes  to  the  Task  Analysis  Plan.  The  contractor  shall  not  modify  the 
organization  or  metiiods  described  after  it  has  been  accepted  by  the  Acquisition 
agency,  without  prior  approval  of  that  agency. 

4.4. 1.6  Review  and  Acceptance  of  the  Plan,  The  Acquisition  agency  will  indicate 
acceptance  or  rejection  of  the  plan  with  comments  within  the  time  specified  in  the 
contract.  If  the  plan  is  rejected,  the  contractor  must  modify  and  resubmit  it  for 
Government  review  until  it  is  accepted. 
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4.4. 1. 7  Equipment  Plan.  The  contractor  shall  include  in  the  Task  Analysis  Plan, 
an  equipment  plan  that  describes  the  extent  to  which  the  actual  system  or  equip¬ 
ment  will  be  employed  during  MTI&A  development  and  validation.  The  MTI&A 
process  requires  scheduled  availability  of  actual  equipment  to  permit  hands-on 
research  of  tasks  by  the  analyst,  to  ensure  that  the  user  can  perform  identified 
tasks  quickly  and  effectively.  The  plan  should  discuss  the  contractor's  equip¬ 
ment  development  schedule.  Include  in  the  plan,  evidence  that  task  analysts 
imderstand  that  the  actual  equipment  must  be  used  to  test  behavioral  cues  of 
procedural  task  steps  during  development  of  task  analysis  worksheets. 

Note  that  the  specification  permits  the  use  of  alternate  equipments  or  mockups, 
but  only  if  approved  by  the  Acquisition  agency.  Especially  on  developing  sys¬ 
tems,  the  hands-on  phases  of  MTI&A  may  precede  the  availability  of  final  ver¬ 
sions  of  the  actual  hardware.  It  is,  nonetheless,  important  that  task  analysis 
research  be  done  on  a  similar  or  simulated  equipment  to  test  the  accuracy  of 
component  location,  accessibility  of  corrective  measures  or  adjustments,  and 
other  concerns  of  the  maintenance  user.  Therefore,  identify  in  the  plan  the 
specific  equipment  to  be  used  including  its  stage  of  development,  where  it  will 
be  used,  whether  it  is  government-  or  contractor-owned,  and  describe  why  an 
alternative  equipment  or  mockup  must  be  used.  Also,  the  plan  must  identify  all 
support  equipment  and  when  test  equipment,  tools,  and  ground  support  equipment 
will  be  ready  for  MTI&A  use.  If  it  is  possible  that  the  equipment  may  become 
unavailable,  the  plan  must  discuss  how  the  contractor  will  ensure  the  accuracy 
of  task  analysis. 

4.4. 1. 8  Equipment  Availability  for  Validation.  The  plan  must  also  demonstrate 
that  the  contractor  has  dedicated  specific  time  periods  to  hands-on  validation  of 
task  analysis  products  as  required  by  the  specification.  All  procedures  and 
illustration  references  of  the  Task  Analysis  Worksheets  and  the  Action  Trees 
must  be  validated  100  percent  by  actual  performance  on  the  subject  system  or 
equipment  to  ensure  the  accuracy  of  the  subsequently  prepared  JPA. 

4. 4. 1.9  Source  Data.  The  plan  must  include  the  contractor's  plan  for  assem¬ 
bling,  checking,  and  using  data  in  task  analysis.  Describe  in  the  plan  the  fypes 
of  data  to  be  used. 

4.4.1. 10  Personnel.  The  resumes  of  task  analysts  and  assistant  task  analysts, 
including  their  pertinent  qualifications,  must  be  included  in  the  plan.  Also,  the 
organization  within  which  the  MTI&A  group  functions  must  be  explained  including 
its  relationships  to  other  cognizant  organizations,  such  as  ILS  or  LSA  depart¬ 
ment,  Engineering,  and  Publications. 

4.4.1.11  QA  and  Scheduling.  The  plan  must  discuss  the  systems,  procedures, 
and  personnel  with  which  QA  will  be  accomplished  in  accordance  with  specifica¬ 
tion  Section  4.  Detailed  schedules  for  each  MTI&A  phase,  including  QA,  must 
be  provided. 


4.5  DrtaSourcw.  The  sources  of  data  for  MTI&A  will  range  from  rough  engineer¬ 
ing  sketches,  preliminary  bills  of  material,  and  verbal  information  (on  develop¬ 
ing  programs)  to  full  data  packages  including  complete  technical  manuals  and 
parts  breakdowns,  LSAR  data,  and  field  maintenance  e:q>erience  and  logs  (on 
fielded  systems).  If  the  task  analysis  is  being  performed  for  a  system  still 
under  development,  early  MTI&A  depends  heavily  on  engineering  data  and  inter¬ 
views  with  designers.  Sometimes,  an  analyst  works  among  the  design  team  and 
affects  design  decisions  (e.g. ,  those  with  human  engineering  considerations). 

The  contractor  must  understand,  however,  that  regardless  of  the  stage  of  equip¬ 
ment  development  at  which  MTI&A  begins,  it  cannot  be  considered  complete  until 
all  input  data  required  by  the  specification  have  been  supplied  and  validated. 
Therefore,  system  design,  hardware  design,  and  the  overall  maintenance  con¬ 
cept  must  be  firm  before  the  requirements  of  the  MTI&A  specification  can  be 
finally  met.  The  system  documentation  available  for  the  preparation  of  mainte¬ 
nance  task  analyses  may  vary  among  systems.  In  axty  case,  the  task  analyst 
should  obtain  the  most  current  revisions  of  system  documents,  and  thereafter 
ensure,  through  rigorous  configuration  control,  that  the  latest  drawings  and 
Information  are  used. 

Effective  MTI&A  requires  that  the  analyst  make  a  thorough  search  for  and  make 
full  use  of  all  valid  information  that  can  contribute  to  a  complete  data  base.  On 
many  contracts,  much  of  the  input  data  for  MTI&A  will  be  found  in  the  formal 
requirements  of  LSAR,  required  by  the  Contract  Data  Requirements  List  (CDRL). 
The  CDRL,  on  DD  Form  1423,  specifies  data  to  be  delivered  by  the  contractor. 
Section  5  of  this  handbook  deals  with  the  efficient  performance  of  MTl&A  when 
LSAR  data  are  available  to  the  analyst.  Section  6  provides  guidance  to  the  ana¬ 
lyst  when  LSAR  data  are  not  available  as  a  foundation  for  MTI&A. 

4. 5. 1  Source  Data  on  New  Systems.  Typically,  the  analyst  can  look  for  the  fol¬ 
lowing  types  of  source  data  to  be  available  in  some  form  for  developing  systems: 

a.  Logistic  Siq)port  Analysis  Record  (LSAR)  —  A  variety  of  summaries  and 
specialized  output  data  that,  if  properly  developed  and  coordinated  with 
MTI&A,  provide  data  pertinent  and  important  to  the  entire  task  analysis 
process.  LSAR  data  and  their  uses  are  explained  more  fully  in  Section 
5  of  this  handbook. 

b.  Design  and  Engineering  Data  —  Drawings,  lists,  specifications,  and 
other  information,  including  functional  block  diagrams ,  schematics, 
timing  diagtrams,  mechanical  or  physical  layouts  and  equipment  speci¬ 
fications  generated  by  designers,  eng^eers,  or  vendors,  to  communi¬ 
cate  technical  details  to  other  functions  (manufacturing.  Integrated 
logistics,  purchasing,  etc.) 


c.  Support  equipment  requirements/ recommendation  data  such  as  Aero¬ 
space  Ground  Equipment  Recommendation  Data  (AGERD),  and  Ground 
Support  Equipment  Recommendation  Data  (GSERD)  —  Data  required  to 
explain  and  justify  the  need  for  support  equipment,  including  standard 
and  specialized  test  equipment. 

d.  Provisioning  Parts  List  (PPL)  —  Equipment  parts  breakdowns  com¬ 
piled  from  early  engineering  design  documents  to  enable  planning  and 
purchasing  of  provisioning  spares. 

e.  Test  Specifications,  Test  Reports  —  That  reflect  equipment  design 
details  and  requirements  and  reports  that  report  testing  of  various 
kinds. 

f.  Preliminary  User  Profile  —  A  government-generated  document  that 
explains  the  level(s)  of  technician  determined  capable  of  maintaining 
the  system  in  the  field. 

g.  Maintenance  Concept  —  Plans,  scope,  policies,  personnel,  and  con¬ 
straints  for  all  maintenance  activities  on  a  given  system. 

h.  Sii)ject  System  Equipments  —  Any  hardware  such  as  mockiq)s,  proto¬ 
types,  development  models,  etc. ,  that  is  sufficiently  similar  in 
function,  parts,  size,  controls,  etc.,  to  provide  early  insight  into 
maintenance  requirements  and  tasks. 

i.  Photographs  —  Of  the  system /equipment  to  help  identify  its  physical 
characteristics. 

j.  Manufacturers'  Literature  —  Commercial  data  such  as  sales  brochures, 
data  sheets,  technical  manuals,  parts  catalogs,  etc. ,  for  off-shelf 
equipment  or  assemblies  macifactured  by  the  contractor  or  contractor's 
vendors. 

k.  Technical  Manuals  —  Either  MIL-Spec  (e.g. ,  TOs,  TMs)  or  commer¬ 
cial  quality  manuals  that  provide  operation  and  maintenance  data  on 
government-furnished  equipment. 

l.  Interviews  —  With  subject  matter  experts  such  as  designers,  engineers, 
maintenance  specialists,  programmers  involved  in  development  or  design 
and  can  provide  insight  into  maintenance  procedures  and  tasks. 

m.  Technical  Proposals  —  Developed  by  the  contractor  or  contractor's 
suppliers,  frequently  provide  early  descriptive  data  to  the  analyst. 

Such  data  must  be  considered  tentative  at  best  and  confirmed  for  accu¬ 
racy  as  soon  as  possible. 
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4.5.2  Source  Data  on  Operational  Sjystems.  The  analyst  should  accumulate  the 
following  types  of  data,  many  of  which  will  be  important  inputs  for  MTI&A  on 
operational  systems: 


a.  Maintenance  Manuals,  Parts  Breakdowns  —  Organizational,  Intermedi¬ 
ate,  or  Depot  level  maintenance  manuals.  Illustrated  Parts  Breakdowns 
(IPBs),  Repair  Parts  and  l^ecial  Tools  Lists,  including  changes  or 
revisions  to  basic  manuals.  (Data  in  Depot  level  manuals  can  be  useful 
even  though  MTI&A  is  intended  for  Organizational  or  Intermediate  main¬ 
tenance  levels. ) 

b.  Time  Compliance  Technical  Orders  (TCTOs)  —  Direction  and  instruc¬ 
tions  on  how  to  implement  system  or  equipment  changes,  perform 
inspections,  or  install  new  equipment. 

c.  Performance  Data  —  Historical  data  relating  to  maintainability,  relia¬ 
bility,  and  supportability  of  systems,  subsystems,  and  components. 

d.  Inspection  Workcards,  Work  Unit  Code  Manuals,  and  Maintenance 
Checklists  —  Technical  instructions  for  maintenance  personnel. 

e.  AFTO  Form  22 's  (Technical  Order  ^stem  Improvement  Reports)  — 

Or  similar  forms,  which  are  intended  to  reveal  improvements  or 
corrections  to  technical  manuals  recommended  by  field  users. 

f.  Test  Equipment  and  Ground  Siqiport  Equipment  Manuals  —  Explaining 
operation  and  maintenance  of  support  equipment  required  in  perform¬ 
ing  maintenance  on  the  subject  [^stem. 

g.  Standard  Operating  Procedures  (SOPs)  —  Detailed  procedures  which 
augment  formal  technical  instructions. 

h.  I>arts  Utilization  Summaries  —  History  of  parts  usage  in  the  field. 

i.  Engineering  Reports  —  Providing  information  on  need  for  design  im¬ 
provements,  etc. 

j.  Field  Engineering  Bulletins  —  Providing  field  personnel  with  necessary 
instructions  on  changes  or  techniques  before  they  become  part  of  more 
formal  documentation,  such  as  TCTOs,  and  manuals. 

k.  Interviews  —  With  engineers,  maintenance  siq^ervisors,  and  technicians 
experienced  in  maintenance  problems,  techniques,  etc. 

l.  Observations  of  Maintenance  in  Progress  —  For  better  understanding  of 
maintenance  processes,  problems,  and  techniques. 
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4.5.3  Configuration  Control  of  Data.  I^stem  hardware  undergoes  frequent  mod¬ 
ification  during  its  design  life  and  operational  and  maintenance  concepts  and  tech¬ 
niques  also  change.  The  analyst  must  be  certain  that  the  data  used  for  MTI&A 
are  valid,  up-to-date,  and  reflect  the  most  advanced  approach  to  maintenance. 

Plans  for  MTI&A  should  include  a  well-defined  system  of  control  and  identifica¬ 
tion  of  all  data  collected.  Identify  the  source  of  each  type  of  data  collected  so 
that  there  is  an  audit  trail  from  the  start  of  MTI&A.  As  mentioned  earlier,  task 
analysis  data  must  be  continuously  marked  up  to  record  technical  changes  and 
generally  be  kept  current  even  after  the  development  of  a  JPA  or  manual  is  in 
progress.  Plan  this  effort  by  develorlng  a  form,  such  as  shown  in  Figure  2, 
with  sufficient  range  to  list  all  types  of  data  (including  interviews,  photos,  etc.), 
when  they  were  obtained,  and  when  they  were  changed,  improved,  or  deleted. 
Aimotate  and  Identify  each  source  document  with  its  title  and  number,  the  orig¬ 
inal  issue  and  revision  date,  page  number,  and  any  other  helpful  information. 
Annotate  LSAR  data  with  the  LSAR  control  number,  output  summary  title  and 
page  number,  date  and  revision  codes,  etc. ,  as  applicable.  Also  identify  equip¬ 
ments  used  for  development  or  validation  of  analysis  products.  Record  the 
nomenclature,  part  or  model  numbers,  serial  numbers,  modification  status, 
and  configuration  of  each  equipment.  For  verbal  data,  record  the  names  of 
personnel  interviewed,  their  organization  and  title,  and  the  date. 

4.5.4  Assessing  and  Validating  Source  Data.  Task  analysts  are  frequently  im¬ 
pressed  by  the  magnitude  and  depth  of  detailed  data  they  have  assembled.  Quite 
often,  though,  the  information  is  partly  incorrect  or  outdated,  or  covers  a 
similar  but  different  model  of  equipment.  Task  identification  should  not  begin 
until  the  analyst  feels  certain  that  the  assembled  data  are  valid.  Some  of  the 
most  important  methods  for  certifying  the  integrity  of  collected  data  are; 

a.  Document  Reviews.  Relevant  documents  and  data  sources  are  compared 
with  the  latest  engineering  drawings,  bills  of  materials,  and  the  actual 
hardware. 

b.  Observation  and  Interview.  The  task  analyst  should  take  advantage  of 
the  availability  of  experienced  maintenance  technicians  and  their 
supervisors.  Observing  and  interrogating  them  while  they  are  per¬ 
forming  work  activities  is  a  practical  method  for  verifying  maintenance 
techniqiies  and  getting  current,  detailed  job  performance  requirements 
especially  for  tasks  for  which  no  documentation  exists. 

c.  Sii>ject  Matter  Expert  (SME)  Review.  Frequent  reviews  by  SMEs  such 
as  system  design  personnel  so  they  are  aware  of  the  data  being  used 
for  analysis  helps  assure  that  the  data  are  current  and  complete. 
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FIGURE  2.  MTI&A  configuration  control  form  (sample). 


4.6  Quality  Assurance  of  Task  Analysis.  To  ensure  an  effective  MTI&A  organization, 
the  contractor  should  necessarily  include  a  QA  function  tuned  to  the  complex  dis¬ 
ciplines  of  task  analysis  and  one  that  starts  to  perform  its  mission  at  the  outset 
of  the  program. 

In  the  development  of  the  various  task  analysis  products  for  technically  complex 
equipment,  the  level  and  amount  of  detail  are  much  greater  and  more  prone  to 
error  than  in  conventional  technical  documentation.  This  is  largely  due  to  the 
greater  detail  requirements  in  the  final  maintenance  aid  to  be  produced  from  the 
MTI&A.  As  the  analyst  constructs  a  task  identification  matrix  or  the  logic  of  an 
action  tree  for  example,  a  simple  misconception  may  have  a  "ripple  effect"  on 
marqr  tasks  and  have  serious  effects  later.  A  competent  quality  assurance  organi¬ 
zation  will  catch  these  errors  and  prevent  their  propagation  into  other  products. 
Quality  assurance  personnel  must  also  eliminate  quality  deficiencies  during  the 
entire  task  analysis  program.  A  dedicated  quality  assurance  (QA)  program  for 
MTI&A  must  also  establish  the  standards  against  which  the  quality  of  each  prod¬ 
uct  will  be  measured  as  it  is  being  developed.  For  example,  the  program  must 
address  and  define: 

a.  The  various  kinds  of  inspections  to  be  accomplished 

b.  The  responsibilities  for  evaluating  quality  and  accuracy 

c.  Means  of  recording  and  controlling  quality  control  procedures 

d.  Means  for  solving  problems  of  deficiencies  in  MTI&A  quality. 

Merely  being  able  to  point  out  unacceptable  data  does  not  accomplish  quality 
assurance.  There  must  also  exist  an  ongoing  organizational  approach  to  correct¬ 
ing  the  procedural  deficiencies  that  create  unacceptable  task  data.  The  con¬ 
tractor's  Quality  Assurance  Plan  must  be  designed  to  ensure  both  quality  and 
accuracy  in  the  finished  product.  Later  in  this  handbook,  the  organization,  pro¬ 
cedures,  and  personnel  necessary  to  monitor  the  planning,  development,  inspec¬ 
tion,  review,  validation,  verification,  and  final  production  stages  of  a  project 
are  discussed.  It  is  therefore  vital  that  the  contractor's  quality  assurance 
organization  is  adequately  staffed  with  personnel  who  understand  MTI&A  and  its 
importance  to  the  ultimate  product  as  well  as  to  the  technician  in  the  field. 

4.7  Schedules  and  Budget.  It  is  not  within  the  scope  of  this  handbook  to  provide 
advice  on  scheduling  and  budgets  for  the  overall  task  analysis.  It  is  appropriate, 
however,  to  point  out  that  in  planning  an  effective  MTI&A  capability,  these  two 
factors  are  of  great  importance.  Developers  who  are  planning  task  analysis  for 
the  first  time  should  understand  that  the  process  is  not  merely  a  data  gathering 
and  outline  stage  for  the  JPA  or  manual.  To  consider  it  as  such  would  be  to 
allocate  too  little  time  and  budget  for  a  particularly  complex  function.  Instead, 
the  contractor  should  understand  that  a  well  organized  and  carefully  considered 


maintenance  task  identification  and  analysis  program  will  provide  the  foundation 
that  will  ensure  that  the  JPA  development  will  be  predictable,  efficient,  orderly, 
and  cost  effective.  In  order  to  lay  this  firm  foundation,  MTI&A  must  be  sched¬ 
uled  and  budgeted  to  allow  for  careful  and  complete  development  with  full  atten¬ 
tion  devoted  to  review,  quality  control,  validation,  and  delivery.  Some  high 
priority  items  the  contractor  should  consider  are  (1)  Task  analysis  for  trouble¬ 
shooting  is  more  costly  and  time-consuming  than  for  nontroubleshooting  tasks 
and  therefore  should  be  given  adequate  time  for  total  research;  (2)  The  timely 
scheduling  of  subject  matter  experts  to  support  the  task  analysis  effort  will 
reduce  false  starts  and  guesswork  on  the  part  of  analysts ;  and  (3)  Scheduling  the 
timely  coordination  of  LSAR  analysis  functions  to  coincide  with  MTI&A  efforts 
will  eliminate  duplicate  costs  and  efforts  of  these  functions. 

4.8  Analysis  and  Analysis  Products.  The  MTI&A  Specification  focuses  on  two  ele¬ 
ments;  analysis  and  analysis  products.  Although  it  is  important  to  discuss  the 
approach  to  effective  preparation  of  products ,  it  is  the  analysis  itself  that  is  the 
substance  of  MTI&A  while  the  products  are  the  recording  of  the  substance.  Some 
contractors  have  felt  that  it  is  the  preparation  and  delivery  of  a  task  analysis 
product  such  as  a  TIM  or  a  Fault  Symptom  List  that  is  important  because  it  is 
contract  deliverable.  To  emphasize  the  paperwork  over  the  careful  research 
needed  to  thoroughly  identify  and  analyze  the  tasks  for  maintenance  as  required 
in  the  specification  is  to  run  the  risk  of  producing  a  set  of  output  documents  that 
may  not  be  accurate  or  complete.  If  they  are  not,  validation  will  not  succeed 
and  the  analysis  will  have  to  be  redeveloped  at  extra  expense.  When  the  follow¬ 
ing  important  ingredients  of  MTI&A  are  applied  to  the  program ,  the  analytical 
process  will  succeed,  enabling  cost-effective  development  of  products  and,  most 
important,  ensure  that  the  ultimate  JPA  will  be  of  maximum  use  to  the  govern¬ 
ment  and  user. 

a.  Qualified  task  analysis  personnel 

b.  Management  attention  to  MTI&A 

c.  Subject  matter  pxpert  (SME)  availability 

d.  Good  source  data 

e.  Dedication  of  actual  equipment  time  for  analyst's  needs 

f.  Careful  planning,  scheduling,  and  funding. 

5.  DEVELOPING  MTi&A  WITH  THE  AID  OF  AN  LSA  DATA  BASE 

The  specification  requires  that  the  contractor  coordinate  the  MTI&A  and  LSA 
functions  when  both  are  incorporated  by  contract.  This  ensures  that  maximum 
use  will  be  made  of  LSA  data,  that  there  will  be  no  significant  data  differences 
resulting  from  Lgistics  support  analysis  and  task  analysis,  and  that  MTI&A  is 


developed  as  cost  effectively  as  possible.  MIL-STD-1388-2  defines  the  standard 
data  elements  that  must  be  satisfied  by  the  contractor.  Various  input  data  sheets 
described  in  this  section  are  required  to  be  filled  out  by  the  cognizant  contractor 
activity  and  are  usually  input  to  a  master  computer  file  (although  they  can  also 
be  manually  developed)  for  accessing  by  various  functions.  These  data  are 
available  for  use  during  their  development  and  as  a  completed  master  file,  and 
this  section  describes  how  the  analyst  can  most  effectively  use  the  data  for  each 
analysis  function. 

5.1  Judicious  Use  of  LSA  Data.  Experienced  task  analysts  will  realize  that  LSAR 
data  can  be  a  most  important  asset  to  the  MTI&A  process.  Analysts  may  also 
be  aware  that  the  quality  and  technical  integrity  of  LSAR  data  varies  consider¬ 
ably  from  one  program  to  another.  Those  LSAR  data  bases  that  are  required  in 
full  by  the  contract  and  completely  implemented  by  the  contractor,  with  a  con¬ 
tinuously  updated  data  base,  are  of  maximum  value  to  the  task  analyst  and  should 
be  fvlly  employed.  Frequently,  however,  a  limited  LSA  is  procured  and  is  only 
performed  during  the  engineering  concept  and  development  model  phases.  In 
such  cases,  LSAR  data  are  limited  and  do  not  remain  current  because  of  changes 
occurring  during  the  final  design  and  production  phase.  Some  LSA  efforts  are 
terminated  after  the  first  analysis  and  development  of  LSARs,  and  it  is  difficult 
for  the  analyst  to  track  the  impact  of  engineering  changes  on  maintenance  proce¬ 
dures  in  a  timely  manner.  This  increases  MTI&A  costs  unless  there  is  a  dedi¬ 
cated  effort  by  the  contractor  and  analysts  to  carry  on  those  LSA  elements  that 
are  vital  to  MTI&A  integrity.  Those  programs  in  which  only  part  of  the  LSAR 
requirements  are  involved  or  in  which  the  available  data  are  late,  incomplete, 
or  limited  to  one  or  two  updates,  will  produce  an  unreliable  data  base. 

The  analyst  may  find,  however,  that  in  the  latter  case  of  questionable  technical 
integrity,  the  LSAR  data  base  is  at  least  a  good  starting  point.  Consider  keep¬ 
ing  such  data  current  as  a  purely  MTI&A  activity.  As  long  as  there  was  an 
initial  logistic  activity  that  developed  an  early  data  base,  the  analyst  can  use 
that  base  as  the  vehicle  for  complete  MTI&A,  so  long  as  it  is  understood  that  no 
one  but  the  analyst  will  keep  it  current. 

Logistics  Support  Analysis  (LSA),  as  defined  by  MIL-STD-1388,  identifies  the 
support  requirements  of  a  system,  or  equipment  including  maintenance  planning, 
support  and  test  equipment,  technical  data,  facilities,  personnel,  and  training, 
among  others.  LSA  outputs  are  in  the  form  of  a  report  (LSAR)  summary  docu¬ 
ment  such  as  shown  in  Figure  3  containing  quantitative  and  qualitative  data 
identifying  and  describing  such  items  as  personnel  requirements  by  skill,  type 
and  number;  support  and  test  equipment;  spares  and  repair  parts,  reliability 
and  maintainability  predictions,  and  facilities.  Without  the  results  of  the  LS.A, 
the  analyst  must  rely  on  creating  and  acquiring  data  and  guidelines  with  limited 
assistance,  as  described  in  Section  6. 


FIGURE  3.  Typical  LSAR  printout 


A  variety  of  LSA  "data  sheets"  are  used  to  record  analysis  data,  Th^  are  des¬ 
ignated  Data  Sheets  A  through  H.  (This  alphabetical  sequence  does  not  denote  the 
sequence  in  which  they  are  prepared. )  The  LSA  program  is  fully  automated  and 
produces  output  summaries  in  the  form  of  computer  printouts  that  will  be  of  vital 
interest  to  the  MTI&A  task  analysts.  Input  data  sheets  E,  F,  and  G,  however, 
are  not  usually  entered  into  the  computer  data  base.  They  contain  descriptive 
rather  than  quantitative  data  and  are  therefore  very  important  to  the  analyst  in 
their  original  form.  A  brief  description  of  all  of  the  pertinent  data  sheets  and 
output  summary  reports  follows. 

5. 1. 1  Data  Sheets  B,  E,  F,  and  G.  The  analyst  should  review  these  sheets  to 
see  if  they  contain  data  pertinent  to  MTl&A  on  the  particular  program.  Data 
sheet  B,  in  addition  to  other  system  data,  includes  Failure  Analysis  data,  item 
function,  and  the  maintenance  concept.  It  contains  data  on  hardware  failure 
modes,  frequency  of  failures,  and  failure  effects  and  is  therefore  an  important 
input  to  the  troubleshooting  task  analysis. 

Data  sheet  E  identifies  requirements  for  special  support  and  test  equipment  and 
new  training  aids.  Data  sheet  F  specifies  requirements  for  any  new  facilities  or 
facilities  modification  to  support  the  program.  Data  sheet  G  identifies  the  need 
for  new  skills  or  training  requirements  for  personnel  to  support  the  system. 

The  analyst  may  be  able  to  examine  these  three  data  sheets  for  general  back¬ 
ground  data  before  proceeding  to  other  LSAR  data, 

5. 1.2  Data  Sheets  A,  C,  H,  and  D.  Data  sheet  D  is  the  core  of  the  MTI&A  pro¬ 
cess  because  it  can  provide  the  analyst  with  the  following: 

1.  Item  (equipment,  system,  component)  to  be  worked  on 

2.  Task  to  be  performed  (for  all  tasks  in  the  system) 

3.  Maintenance  level  (e.g. ,  O  or  I) 

4.  Descriptive  instructions  on  how  to  accomplish  the  task 

5.  Personnel  and  training  requirements  for  the  task  (who  performs  the 
task) 

6.  Identifies  tools  and  test  equipment  required 

7.  Time  required  to  perform  the  task. 

The  other  data  sheets  A,  C,  and  H  contain  information  that  becomes  part  of  out¬ 
puts  of  the  LSA  process,  reports  (LSAR)  or  summaries.  These  data  sheets  are 
coded  for  computer  entry  and  are  of  limited  use  to  the  analyst.  However,  the 
summaries  that  result  from  these  data  are  of  great  importance  to  the  analyst 
and  are  therefore  discussed  in  the  following  paragraphs. 


5.1.3  Output  Summary  Reports.  The  data  entered  into  the  LSAR  automated  sys¬ 
tem  will  be  stored  and  used  to  produce  reports  that  are  tailored  to  the  particular 
system/equipment  end  use.  The  MTI&A  analyst  should  therefore  examine  the 
contract  CDRL  and  related  Data  Item  Descriptions  (DIDs)  to  determine  which 
summaries  are  required  and  available. 

Some  of  the  LSAR  summaries  that  the  MTI&A  analyst  will  need,  if  they  are 
available,  are; 

1.  Direct  Annual  Maintenance  Manhours  by  Skill  Specialty  Code  and  Level 
of  Maintenance.  This  report  siunmarizes  the  manpower  required  to  support 
one  system  for  a  year.  It  defines  the  Air  Force  Specialty  Code  (AFSC )  or  Mili¬ 
tary  Occupational  Specialty  (MOS)  levels  required  for  staffing  at  each  level  of 
maintenance. 

2.  Personnel  and  Skill  Summary.  This  report  is  an  expansion  of  the  Sum¬ 
mary  just  described.  It  defines  the  detail  concerning  each  task  performed  by 
each  type  of  technician. 

3.  Reliability  and  Maintenance  Summary.  This  report  lists  the  unsched¬ 
uled  maintenance  tasks  and  the  10  most  important  scheduled  maintenance  tasks 
both  by  frequency  and  annual  manhours  consumed. 

4.  Maintenance  Allocation  Sianmary.  This  report  summarizes  data  sheet 
inputs  related  to  (a)  the  maintenance  plan  and  concept,  (b)  repair  parts  list,  (c) 
tool  and  test  equipment  allocations,  (d)  the  available  technician  skills  and  man¬ 
power  allocation,  (e)  the  maintenance  levels  (e.g. ,  O,  I,  or  Depot)  for  each 
maintenance  task.  This  summary  printout  explains,  therefore,  the  responsi¬ 
bility  for  the  performance  of  each  maintenance  fimction  on  each  component  of  the 
system . 

5.  Support  and  Test  Equipment  Utilization  Summary.  This  summary  lists 
each  item  of  support  equipment  by  type.  It  gives  the  part  number  and  name  of 
the  support  and  test  equipment  and  then  lists  every  task  on  which  it  is  used. 

6.  System  Ten  High  Report.  This  summary  reports  those  maintenance 
actions  that  have  high  failure  rates,  high  manhour  consumption,  and  high 
repair  times. 

7.  Repair  Parts  Summary.  A  listing  of  repair  parts  by  each  maintenance 
level  (e.g. ,  O,  1,  or  Depot),  or  by  a  combination  of  Maintenance  levels. 

8.  Failure  and  Effects  Summary.  This  summary  reflects  Failure  Mode 
and  Effects  Analysis  (FMEA)  data  performed  under  LSA  and  is  a  primary  source 
of  data  for  the  troubleshooting  task  analysis  because  it  identifies  corrective  and 
preventive  maintenance  tasks. 
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5.2  Optimum  Use  of  LSAR.  A  coordinated  MTI&A/LSA  effort,  in  which  contractor 
logistic  support  engineers  and  maintenance  task  analysts  pool  their  efforts  and 
knowledge,  can  have  the  following  good  effects: 

a.  Interaction  between  the  two  contractor  functions  will  provide  the  best 
data  possible.  Each  will  benefit  from  knowing  and  serving  the  contract 
and  user  requirements  of  the  other. 

b.  There  will  be  minimal  duplication  of  effort. 

c.  There  will  be  minimal  conflict  in  the  data  used  throu^out  the  project. 

d.  Data  processing  can,  if  properly  planned,  satisfy  all  requirements  from 
the  same  data  base. 

e.  The  MTI&A  analyst  can  utilize  LSAR  data  sheets  by  neatly  annotating 
them,  as  appropriate.  The  specification  permits  handwritten  entries 
on  output  summaries,  added  or  deleted  columns,  etc. ,  as  approved  1^ 
the  Acquisition  agency.  Samples  of  proposed  printouts  with  proposed 
annotations  and  notes  must  be  submitted  as  part  of  the  MTI&A/LSA 
Coordination  Plan.  The  requirements  for  the  plan  are  listed  in  3. 5. 1, 1 
of  the  specification. 

5.3  Performing  Task  Identification.  Task  identification  is  the  process  by  which  the 
contractor  defines  all  hardware  items  and  related  tasks  necessary  for  carrying 
out  the  system  maintenance  concept  and  for  providing  complete  procedural  data 
for  technicians  at  either  O  or  I  level,  or  both.  The  results  of  the  task  identifica¬ 
tion  process  are  recorded  on  the  Task  Identification  Matrix  (TIM)  form.  On 
LSAR-based  MTI&A,  the  analyst  should  consider  using  the  existing  LSAR  sum¬ 
maries  for  the  TIM.  Althou^  all  data,  including  LSAR,  must  be  checked  care¬ 
fully  by  the  analyst  before  it  is  used,  the  information  in  5.3.1  provides  an 
excellent  starting  point  for  the  analyst. 

5,3.1  Gathering  Source  Data  for  the  TIM.  The  analyst  should  consult  a  variety 
of  LSAR  data  to  aid  development  of  the  TIM.  LSAR  data  sheets  A,  B,  £,  and  G 
provide  important  planning  and  background  information  for  the  analyst.  Formal 
name  and  part  number  for  each  item  can  be  found  on  data  sheet  H,  which  is  pre¬ 
pared  for  each  numbered  part  in  the  system  along  with  data  to  identify  the  item 
reference  designator.  Data  sheet  D  should  contain  a  narrative  description  of 
each  task  required  for  each  maintenance  significant  O&I  item,  (e.g. ,  replace 
brake  assembly). 

The  analyst,  however,  will  get  more  use  from  output  summary  reports  of  these 
data  sheets  than  the  data  sheets  themselves.  If  the  summaries  are  available, 
the  analyst  can  regard  most  of  the  data  sheets  only  as  reference  material  except 
for  sheets  D,  E,  and  G. 
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5.3.2  Filling  Out  the  TIM  form.  Ideally,  the  analyst  can  request  from  LSAR 
specialists  or  programmers  an  actual  TIM  printout  such  as  shown  in  Figure  4, 
instead  of  adapting  or  modifying  printouts  for  TIM  use.  This  approach  has  the 
economical  benefit  of  eliminating  all  depot  parts,  producing  a  much  smaller  TIM 
document.  If  such  TIM  printouts  are  not  practical  however,  a  Repair  Parts  Sum¬ 
mary  (Figure  5),  Maintenance  Allocation  Summary  (Figure  6),  or  a  provisioning 
document  output  (Figure  7)  can  be  adapted.  This  is  done  by  adding  or  pasting 
down,  a  blank  preprinted  maintenance  function  matrix  to  the  appropriate  LSAR 
summary  printout  (as  shown  in  Figure  8)  that  provides  the  best  O  and  I  equip¬ 
ment  breakdown. 

The  maintenance  functions  that  should  ordinarily  be  covered  in  the  matrix  col¬ 
umns,  to  the  extent  they  are  appropriate,  are  adjust,  align,  calibrate,  checkout/ 
troubleshoot,  clean,  disassemble/assemble,  replace,  lubricate,  remove /install, 
repair,  service.  Maintenance  functions  can  also  be  coded  as  shown  in  Figure  4. 

If  the  system  requires  particular  maintenance  functions  such  as  "inspect, "  or 
"diagnostic,"  to  indicate  that  the  component  is  checked  or  diagnosed  by  a  diag¬ 
nostic  program  as  in  Figure  4,  the  analyst  should  add  it  to  the  columns. 

The  column  headings  across  the  top  of  the  matrix  are;  (1 )  Codes  column  for 
equipment  breakdown  (e.g. ,  FGC  Codes);  (2)  Description  coliunn  in  which  the 
item  (subsystem,  assembly,  subassembly,  or  part)  is  identified;  (3)  the  Part 
Number  column,  where  the  item  part  number  is  recorded;  and  (4)  the  various 
"functions"  columns  for  each  of  the  maintenance  functions.  Depending  on  the 
LSA  document  used  as  a  TIM  base,  these  columns  may  be  in  another  sequence 
on  the  TIM,  than  listed  here.  The  analyst  may  find  it  beneficial  to  add  a 
"Reference  Designator"  column  for  heavily  electronic  systems.  For  many  sys¬ 
tems,  reference  designators  are  set  forth  in  schematic  diagrams  to  identify  each 
equipment  item  in  terms  of  its  location  and  function  within  the  system. 

The  intersection  of  each  item  or  part  listing  in  the  part  column  of  the  TIM  form 
with  a  "Maintenance  Function"  coltunn  is  called  a  "cell. "  Each  cell  defines  a 
theoretically  possible  task.  The  entries  to  be  made  in  each  cell  indicate  the 
actual  tasks,  if  any,  to  be  performed  on  each  hardware  item,  and  the  mainte¬ 
nance  level  at  which  each  is  to  be  performed. 

5. 3. 2, 1  Code  and  Description  Columns.  The  Code  columns  of  the  TIM  are 
Intended  to  show  the  relationship  and  subordination  of  each  system,  assembly, 
subassembly  and  part  that  is  maintainable  at  the  O  or  I  level.  In  most  LSA-based 
programs,  an  adequate  system  coding  such  as  Functional  Group  Codes  (FGC 
codes)  will  be  readily  available  to  the  analyst,  either  as  part  of  the  LSA  Repair 
Parts  summary  or  provisioning  document.  If  no  such  system  is  available  to 
satisfy  the  specification  requirements,  consult  Section  6  of  this  handbook. 
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FIGURE  4.  Example  of  basic  task  identification  matrix  —  computer  printout. 


*1L  LCVfLS  n*  HAINltWANCf 


ii 


♦ 

I  I 


II 

»  X 
«  « 
*s 


e  «  c 

??? 


a  #  ¥  < 

••  9  r  i 


I  I 
9 
9 
I  I 


I  ^  m 
I  I  I 
^  c 
'  r  m 
r 
I  I 
9  9 
9  9 


22it9999Z 

99999999»^ 

I  I  <  I  I  I  I  I  I 

t  I  I  I  I  I  4  t  I 

999999999 

999^90^^9 

mm9 »^999# 
mm999999^ 
mm999999*m 
mm9  999  9  9- 


9  9—  9  9  ** 


9  9—  —  — 


I  I 

9 

,  ? 


I  t 

9  9 
9  9 
(  I 

9  f 
9  — 
9  — 
9  — 


9  9  m» 
9  9  9  — 
9  9  9  9 
9  9  9  — 

(III 


TTTT 

9  9  9  9 

?e  9  9 
I  I  I 

9  9  9  9 
99  9  — 
99  9  - 
9  9  9  — 


^  *  **  **  ** 

S—  *  —  *•  "• 

O  9  9  O  9  9  99S<fc<*i^ 

^9  «  <  9  9  -  ------ 


9  L 

9  9  9  9- 


sS  . 

^90 

9—2 


1^  4  9 


44«4<4449««999999«9a 

099999909999999999999 

9990999999  99099999999 


I  ^  9  •  •  • 


^  ^ 
099999 
^  ^  N  ^ 

9  9  0  9  do 


FIGURE  5.  Sample  of  repair  parts  summary  for  TIM  development. 
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FIGURE  6.  Sample  maintenance  allocation  summary  for  TIM  development. 
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FIGURE  8.  LSAR  printout  used  as  TIM 


5. 3. 2. 2  TIM  Cells.  When  complete  LSA  data  are  available,  many  of  the  analyst's 
decisions  for  TIM  cell  entries  will  have  been  decided  by  LSA  specialists.  TIM 
data  may  therefore  exist  if  the  following  LSA  data  are  available. 

a.  If  a  current  Maintenance  Allocation  Summary  exists,  it  will  provide  the 
analyst  with  answers  to  the  questions: 

—  Can  a  maintenance  function  be  performed  on  this  item? 

—  At  what  level  of  maintenance,  O  or  I  or  both,  will  the  task  be 
performed? 

The  only  major  decisions  left  for  the  analyst  on  task  identification  would 
be  to  determine  where  the  task  should  be  documented  by  answering  these  questions: 

—  Is  the  task  too  simple  to  be  included  in  a  manual?  (Leave  a  blank 
in  right  portion  of  cell.) 

—  Is  the  task  a  fixed  procedure;  one  that  involves  no  checkout  or 
troubleshooting  by  the  user?  (Enter  a  J  for  JGM  in  the  cell.) 

—  Is  the  task  one  that  requires  checking  and  trouble  diagnosis? 

(Enter  an  L  for  LTTA  in  the  cell.) 

b.  If  no  current  Maintenance  Allocation  Summary  exists,  the  analyst  should 
use  a  Repair  Parts  Summary  or  a  Provisioning  List  summary  report  as  the  foun¬ 
dation  for  the  TIM.  Either  document  should  provide  the  answers  to  the  following 
task  identification  questions: 

—  What  is  the  item  name  and  description? 

—  At  what  level  of  maintenance  should  it  be  repaired  or  replaced? 

—  What  is  the  FGC  code? 

—  What  is  the  item  part  number? 

With  such  a  complete  part  breakdown,  the  analyst  may  need  only  to  add  the  main¬ 
tenance  function  matrix  to  printout  sheets,  as  in  Figure  8,  or  have  these  columns 
printed  by  the  computer,  as  in  Figure  4.  In  any  case,  the  analyst  will  find  most 
of  the  data  needed  to  identify  all  tasks  on  the  following  LSA  data  sheets: 

Data  Sheet  D  —  This  sheet  is  entitled  Maintenance  and  Operator  Task  Analy¬ 
sis.  It  provides  the  following  answers  to  complete  the  data  needs  of  the  MTI&A 
analyst.  (See  Figure  9.) 

—  What  task  is  to  be  performed  on  each  item  and  at  what  maintenance 
level? 
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FIGURE  9.  Sample  input  data  sheet  D  used  in  TIM  development. 


—  How  must  the  task  be  performed? 

—  What  type  of  personnel  can  perform  the  task? 

—  What  support  and  test  equipment  is  required  for  the  task? 

Data  Sheet  G  —  This  sheet  is  entitled  "Skill  Evaluation  and  Justification” 
(Figure  10).  It  answers  the  following  questions  concerning  maintenance  person¬ 
nel  to  support  the  system. 

—  Are  there  any  physical  or  mental  requirements? 

—  Are  there  peculiar  educational  requirements  (such  as  specific 
subjects,  degrees,  or  licenses?) 

—  Is  there  additional  training  required?  What  does  it  consist  of? 

At  each  cell  (i.  e. ,  the  intersection  of  a  TIM  equipment  item  and  a  maintenance 
function  column),  the  analyst  must  decide  from  all  of  this  available  data,  includ¬ 
ing  subject  matter  expert  interviews,  if  a  maintenance  task  is  to  be  performed 
on  this  item  and  if  so,  what  type,  and  what  level?  The  codes  to  be  entered  in 
each  cell  must  be  drawn  from  the  list  shown  in  Figure  11. 

5.3.2. 3  Ensuring  TIM  Completeness.  Omission  of  any  hardware  item  from  the 
TIM  can  result  in  omission  of  one  or  more  tasks  from  the  data  base,  and  hence 
from  the  JPAs.  It  is  therefore  critical  that  the  analyst  prepare  and  check  the 
list  of  hardware  items  with  great  care,  and  see  that  it  is  thoroughly  reviewed 
for  completeness  by  a  subject  matter  expert  (SME). 

5. 3. 2. 4  Checking  the  LSA  Task  Identification.  The  LSA  summaries  and  data 
sheets  reveal  most  of  the  tasks  associated  with  a  system  or  equipment.  If  there 
are  equipment  items,  however,  for  which  the  LSA  data  have  not  supplied  the 
decision  on  task  identification,  the  analyst  must  make  task  decisions  from  other 
data.  Where  cells  contain  no  task  decisions,  the  analyst  must  identify  them 
through  existing  equipment  descriptions  or  task  descriptive  data,  or  from  ex¬ 
perience  with  similar  equipment  items  by  the  subject  matter  expert,  or  the 
analyst.  Section  6  discusses  in  more  detail  the  task  identification  process  for 
those  situations  where  there  is  no  satisfactory  LSA  data  base. 

5.3. 2. 5  Assigning  Each  Task  to  a  Manual,  Once  the  analyst  has  identified 
basic  tasks  with  O  or  I  entries  or  blanks  for  nontasks,  the  rig^t  part  of  each  cell 
identified  for  tasks  must  be  annotated  to  identify  the  expected  application  for  the 
task  (i.e. ,  in  what  manual  will  the  task  be  described).  If  the  task  is  for  fixed, 
nontroubleshooting  procedures,  enter  "J"  for  JGM  in  the  cell.  If  it  is  for  a 
checkout  or  troubleshooting  procedure,  enter  "L”  for  LTTA  in  the  cell.  If  the 
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FIGURE  10.  Input  data  sheet  G  for  use  in  TIM  development 
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Organizational  level  task  to  be  Included  in  a  JGM 

Intermediate  level  task  to  be  included  in  a  JGM 

Organizational  level  task  to  be  included  in  a  LTTA 
Intermediate  level  task  to  be  included  in  a  LTTA 

Organizational  level  task  not  to  be  Included  in  a  JGM  or  LTTA 

Intermediate  level  task  not  to  be  included  in  a  JGM  or  LTTA 

Task  to  be  included  in  both  Organizational  and  Intermediate  level  JGMs, 
but  method  of  accomplishment/procedure  differs  for  each 

Task  to  be  included  in  both  Organizational  and  Intermediate  level  LTTAs, 
but  method  of  accomplishment/procedure  differs  for  each 

Organizational  level  task  performed  by  automatic  self-test  equipment  (BITE  i 

Intermediate  level  task  performed  by  automatic  test  equipment  lATEi 

No  such  task  required  at  O  or  1  level 

A  decision  Is  needed  —  "is  there  such  a  task'’"  "At  what  level'’"  (Interim  code) 


Organizational  level  task  -  A  decision  on  JGM  or  LTTA  inclusion  is  needed  (Interim  codei 

Intermediate  level  task  -  A  decision  on  JGM  or  LTTA  inclusion  is  needed  (Interim  code^ 


Task  to  be  included  in  a  JGM  -  A  decision  as  to  maintenance  level  is  needed  (Interim  code 


Task  to  be  Included  in  a  LTTA  -  A  decision  as  to  maintenance  level  Is  needed 
(bterlm  code) 


FIGURE  11.  Basic  TIM  codes. 
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task  will  be  satisfactorily  performed  by  automatic  test  equipment  including  Built- 
in  Test  Equipment  or  BITE,  as  determined  by  LSA  data,  the  second  entry  is  "A." 
If  the  analyst  determines  that  the  task  is  too  simple  or  unimportant  to  require 
coverage  in  a  manual,  leave  the  second  entry  in  the  cell  blank. 

5. 3. 2. 6  Notes  Column.  The  analyst  should  consider  the  Notes  column  as  a  con¬ 
venient  way  to  record  significant  facts,  or  data  generated  or  gathered  during  TIM 
development  for  later  use.  Information  such  as  pertinent  LSAR  revision  levels, 
or  deficiencies  in  the  LSA  data,  interrelationships  between  tasks,  reasons  for 
further  resolution  (?)  entries,  special  information  such  as  techniques  or  prob¬ 
lems  unearthed  during  research,  can  be  of  significant  value  during  later  analyses 
efforts. 

5. 3. 2. 7  Expanded  TIM.  The  specification  defines  expansion  of  the  Basic  TIM 
to  accommodate  special  information  about  the  identified  tasks  where  the  Acquisi¬ 
tion  agency  has  designated  a  requirement.  From  a  complete  LSAR  data  base, 
the  analyst  can  request  numerous  types  of  data  edits  information  through  com¬ 
puter  programming.  When  expansion  is  required,  the  analyst  should  develop  the 
TIM  form  to  allow  for  additional  columns  of  summary  printout  or  manually 
entered  data  or  a  separate  form  to  be  attached  to  the  TIM  if  the  data  does  not 
lend  itself  to  additional  columns.  The  TIM  can  be  expanded,  for  example,  to 
include  data  such  as: 

—  Depot  level  breakdown  of  items 
—  Task  performance  times 

—  Tasks  to  be  considered  for  special  skills  training 
—  Task  Frequency  (e.g. ,  on  preventive  maintenance  tasks). 

5.4  Performing  a  User  Analysis.  A  complete  LSA  data  base  contains  all  of  the 
information  required  in  User  Analysis.  The  analyst  should  analyze  Data  sheet 
C  and  the  printout  called  Personnel  and  Skill  Summary  and  develop  the  MTI&A 
User  Profile  accordingly. 

5.4.1  Data  Sheet  C.  This  sheet  lists  the  estimated  user  characteristics  and 
answers  the  following  questions  that  are  important  in  performing  a  User  Analy¬ 
sis.  See  Figure  12  for  pertinent  columns. 

—  What  is  the  skill  level  of  personnel  required  to  accomplish  each  task? 
Data  sheet  C,  for  example,  supplies  the  answer  in  directing  that  the 
task  must  be  accomplished  by  persons  with  Basic  skills  (i.e. ,  usually 
for  personnel  in  pay  grades  E-4  and  lower),  or  Intermediate  skills 
(i.e. ,  usually  for  E-5  personnel),  or  Advanced  skills  (i.e. ,  usually 
for  E-6  and  above). 
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—  What  is  the  skill  specialty  necessary  to  accomplish  the  task?  Skill 
specialties  are  coded  for  each  military  agency.  For  example,  Air 
Force  skill  specialties  found  in  the  Data  sheet  C  listings  are  derived 
from  AFR  36-1,  Officer  Classification  Manual  and  AFR  39-1,  Airman 
Classification  Manual. 

—  Is  the  selected  skill  specialty  inadequate  and  is  additional  training  there¬ 
fore  required?  This  is  particularly  important  to  the  analyst  who  must 
accommodate  this  skill  deficiency  by  adding  sufficient  procedural  detail 
in  the  MTI&A  data  base  to  overcome  the  deficiency.  Additional  data 
on  these  deficiencies,  which  must  be  pointed  out  in  the  user  profile,  can 
be  foimd  on  Data  sheet  G. 

5.4.2  Data  Sheet  G.  This  data  sheet  (see  Figure  13)  defines  and  justifies  the 
need  for  any  new  skills  beyond  the  capability  of  the  appropriate  skill  specialty 
listed  on  sheet  C.  When  the  "SS  Eval"  column  of  sheet  C  is  checked,  the  ana¬ 
lyst  should  go  to  sheet  G  to  determine  the  requirements  for  additional  training. 

An  A  in  the  SS  Eval  indicates  that  the  skill  specialty  is  adequate,  an  M  indi¬ 
cates  that  modification  (additional  training)  is  needed,  and  an  E  indicates  that 
there  is  no  appropriate  skill  specialty  and  a  new  one  must  be  established.  Of 
particular  importance  to  the  analyst  in  developing  the  Definitized  User  Profile 
are  those  parts  of  sheet  G  which  answer  the  following  questions  about  the  user; 

—  Are  there  any  unique  physical  or  mental  attributes  required  of  person¬ 
nel  before  they  are  qualified  to  perform  the  task? 

—  Are  there  any  particular  educational  requirements  that  personnel  must 
satisfy  before  they  can  acquire  the  skill  to  perform  the  task  or  attain 
the  Skill  Specialty  code  ? 

—  If  there  are  requirements  for  additional  training,  what  does  it  consist 
of  (type  of  course,  length  and  site  of  course,  and  student  prerequisites)? 

5.4.3  Personnel  and  Skill  Summary.  This  report  summarizes  the  data  from  the 
Data  sheet  C.  The  analyst  will  find  that  this  summary  (see  Figure  14),  if  avail¬ 
able,  will  form  the  foundation  of  the  user  analysis.  Analyze  tlie  skill  specialty 
codes  required  for  maintenance  by  consulting  AFR  36-1  or  AFR  39-1  and  con¬ 
sult  the  LSA  analyst  to  determine  whether  the  skill  specialty  is  adequate.  If  not, 
explain  in  the  user  profile  the  extent  to  which  this  inadequacy  must  be  supported 
by  additional  tasks  or  task  detail. 

5.4.4  Using  the  Preliminary  User  F>rofile.  In  the  early  stages  of  a  contract, 
before  Personnel  and  Skills  data  have  emerged  from  the  LSA  system,  the  ana¬ 
lyst  must  depend  on  a  Preliminary  User  Profile  supplied  by  the  Acquisition 
agency.  It  will  define  the  general  background  and  training  of  apprentice  and 
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FIGURE  13.  Sample  data  sheet  G  for  use  in  user  analysis. 


experienced  technicians  who  will  be  responsible  for  maintenance  of  the  system. 

It  will  provide  the  analyst  with  data  on  which  to  base  MTI&A  planning,  such  as 
the  user  technician's  reading  level,  training  school  courses  and  other  educa¬ 
tional  background,  a  skills  inventory,  expected  normal  work  conditions,  and  the 
level  of  supervision.  Later,  in  coordination  with  the  LSA  specialists,  the  ana¬ 
lyst  shall  develop  a  more  comprehensive  Definitized  User  Profile  which  will  be 
used  by  the  JPA  developer. 

5.4.5  Developing  the  Definitized  User  Profile.  The  Definitized  User  Profile  is 
developed  from  data  accumulated  and  studied  by  the  analyst  during  User  Analysis. 
It  therefore  will  be  developed  from  the  LSA  personnel  and  skills  data.  The 
MTI&A  analyst  shall  develop  this  detailed  profile  for  review  and  assurance  by 

all  contractor  subject  matter  experts  and  the  Acquisition  agency  personnel,  that 
the  definition  of  the  actual  maintenance  technician  user(s)  culled  from  LSA  infor¬ 
mation  is  accurate  and  complete. 

If  the  analyst  determines  that  the  Definitized  User  Profile  establishes  a  user  that 
is  different  from  that  described  by  the  Acquisition  agency,  the  contractor  should 
convene  a  conference  to  explain  and  receive  concurrence  in  the  intended  changes. 
This  conference  will  clarify  the  definition  of  the  individuals  who  will  be  using  the 
task  details  in  the  JPA  including  improved  training  requirements.  The  contrac¬ 
tor  may  find  it  extremely  helpful  to  observe  government-defined  users  in  their 
training  setting  or  in  actual  performance  of  their  maintenance  duties,  so  as  to 
verify  that  their  skills  and  knowledge  equate  with  the  profiled  user.  The  product 
of  this  conference  is  an  approved,  final,  Definitized  User  Profile,  which  will 
guide  the  further  task  analysis  process  and  the  JPA  developers. 

5.5  Performing  the  Support  Equipment  Analysis.  The  contractor  must  perform  a  de¬ 
tailed  analysis  of  all  common  and  special-purpose  test  equipment,  special  tools, 
and  ground  support  equipment  that  is  necessary  to  maintain  the  system  or  equip¬ 
ment  at  O  or  I  level.  This  research  will  include  understanding  the  functions  and 
operation  of  all  support  equipment  and  consolidating  this  data  for  later  use  by 
the  analyst  and  the  JPA  developer.  The  analyst  must  be  quite  certain  in  this 
analysis  that  the  support  equipment  list  is  complete  and  accurate  because  the  list 
will  determine  level  of  task  detail  and  affect  the  number  and  level  of  tasks  to  be 
developed  for  the  user.  Note  that,  as  used  in  the  specification,  support  equip¬ 
ment  includes  special  tools,  metrology  and  calibration  equipment,  performance 
monitoring  and  fault  isolation  equipment,  maintenance  stands,  and  handling  de¬ 
vices  required  for  maintenance  of  the  system.  LSAR  Data  sheet  E  and  resulting 
summary  reports  provide  the  source  data  for  this  analysis. 

5.5.1  Data  Sheet  E.  This  sheet  (Figure  15)  describes  and  justifies  the  require¬ 
ments  for  support  and  test  equipment  necessary  to  operate  or  maintain  the  system. 


58 


SUPPORt  AND  TEST  EQUIPMENT  OR  TRAINING 


FIGURE  15,  Sample  of  data  sheet  E  for  use  in  developing  support  equipment  analysis. 


Data  sheet  £  will  provide  the  analyst  with  answers  to  the  following  questions 
which  are  necessary  to  perform  a  complete  Support  Equipment  Analysis. 

—  What  testing,  measuring,  diagnostic  tools,  and  test  equipment  are 

required?  (These  are  identified  by  name,  model  number,  part  number, 
and  physical  size. ) 

—  What  functions  will  the  item  perform  (e.g. ,  the  type,  accuracy,  and 
range  of  readouts )  ? 

—  What  additional  skills  or  training  must  be  provided  before  the  technician 
can  use  it  properly?  For  example,  it  may  indicate  that  special  contrac¬ 
tor  training  school  must  be  completed  before  the  operating  skills  of  the 
technician  will  be  adequate. 

5.5.2  Support  Item  Summaries.  The  analyst  will  use  one  or  more  of  the  follow¬ 
ing  printout  reports  summarizing  support  and  test  equipment  data  as  a  data  source 
for  developing  the  Support  Equipment  Guide. 

a.  Support  and  Test  Equipment  Utilization  Summary.  This  summary  shows 
the  analyst  how  each  item  is  used  —  by  maintenance  level.  In  addition  to  provid¬ 
ing  the  MTI&A  analyst  with  an  excellent  data  source  for  the  Support  Equipment 
Analysis,  this  summary  also  provides  the  data  to  check  the  accuracy  and  com¬ 
pleteness  of  the  TIM.  As  shown  in  Figure  16,  for  each  tool  or  support  equipment 
item ,  there  is  a  description  of  each  maintenance  task  for  which  the  item  is  re¬ 
quired  and  the  maintenance  level  at  which  the  task  is  performed. 

b.  Tool  and  Equipment  Requirements  Summary.  This  report  provides  a 
listing  of  all  tools  and  test  equipment  as  they  are  used  at  either  or  both  O  or  I 
maintenance  level. 

5.5.3  Developing  the  Support  Equipment  Guide.  The  analyst  should  follow 
these  steps  to  produce  an  acceptable  Siqiport  Equipment  Guide: 

a.  Assemble  and  study  all  of  the  LSA  data  on  support  equipment. 

b.  On  each  page  of  the  guide,  record  the  title  of  the  system  or  equipment, 
the  date  the  guide  was  developed,  and  the  task  analyst's  name  (see  Figure  17). 

c.  For  each  item,  list  all  of  the  functions  for  which  it  is  used.  Consult 
commercial  manuals  that  describe  each  special  tool  and  test  equipment  and  the 
LSAR  data  for  its  uses. 

d.  Indicate  the  name  and  number  of  each  item  of  test  equipment  or  special 
tool  used.  Identify  the  item  by  AN  designation,  if  assigned,  or  the  manufac¬ 
turer's  designation.  Common  types  such  as  voltmeters,  signal  generators,  etc. , 


for  developing  support  equipment  guide. 


must  be  listed.  A  special  tool  is  any  tool  not  normally  found  in  a  mechanic's 
tool  kit. 

e.  In  the  personnel  assumptions  column,  explain  clearly  the  assumptions 
to  be  made  regarding  the  behavioral  skills  and  knowledge  the  user  must  possess 
to  perform  the  function.  Also  explain  the  information  and  directions  that  will 
have  to  be  provided  in  the  JPA  procedures  using  the  item. 

f.  In  the  standard  statements  column,  the  analyst  must  list  all  of  the  exact 
statements  to  be  made  in  the  Task  Steps  portion  of  the  Task  Analysis  Worksheets 
and  the  JPAs  each  time  the  function  is  needed.  The  statement  should  consist  of 
as  many  of  the  actual  words  to  be  used  when  a  certain  category  of  data  is  to  be 
used  in  the  tasks.  Take  care  that  wording  is  consistent  between  similar  or  iden¬ 
tical  MTI&A  task  data.  In  determining  standard  statement  wording,  use  the 
Definitized  User  Profile  and  consider  user  knowledge,  skills,  and  technical  dif¬ 
ficulty  in  operating  the  item. 

5.6  Performing  the  Level  of  Detail  Analysis.  If  the  capabilities  of  the  users  are  over¬ 
estimated,  they  will  not  be  able  to  follow  the  instructions  in  the  JPA.  If  the 
instructions  merely  state  "Check  the  waveform  at  Pin  21001,  "  and  the  techni¬ 
cians  do  not  know  where  Pin  21001  is,  what  the  waveform  should  be,  how  to 
check  it,  or  what  the  equipment  state  should  be  before  making  this  check,  they 
cannot  perform  this  task.  Too  much  detail,  on  the  other  hand,  slows  down  task 
performance  and  can  also  increase  errors  in  performance  because  users  may 
tend  to  avoid  using  the  JPA  if  it  forces  them  to  wade  through  more  detail  than 
needed.  Arriving  at  the  proper  level  of  detail  for  task  analysis  is  important. 

The  analyst  must  determine  from  the  Definitized  User  Profile  and  its  LS.A  data 
sources  (Data  sheets  C  and  G  and  Personnel  and  Skill  Summary)  the  level  of 
instructions  that  are  appropriate  to  the  JPA  reader.  The  Level  of  Detail  Anal¬ 
ysis  should  be  performed  in  conjunction  with  or  immediately  following  the  User 
Analysis  because  the  information  concerning  user  skills,  capabilities,  training 
deficiencies,  technical  experience  that  it  provides  are  the  same  criteria  from 
which  to  develop  the  Level  of  Detail  Guide.  For  example,  if  the  Definitized 
User  Profile  dictates  that  the  user  has  the  knowledge  and  skills  to  use  an  oscil¬ 
loscope,  then  the  Level  of  Detail  Guide  will  reflect  that  capability  by  excluding 
details  of  oscilloscope  operation.  Conversely,  if  the  User  Profile  shows  that 
the  user  will  not  have  knowledge  or  experience  in  the  use  of  a  piston  ring  groove 
wear  gage,  then  the  Level  of  Detail  Guide  will  require  specific  in-text  detail 
each  time  the  gage  is  used  in  a  task. 

5.6. 1  Developing  the  Level  of  Detail  Guide.  The  Level  of  Detail  Guide  is  a  state¬ 
ment  of  how  detailed  the  information  must  be,  based  upon  what  is  known  about 
the  skills  of  maintenance  personnel  and  about  the  equipment  systems.  The  ana¬ 
lyst  shall  develop  the  Guide  in  accordance  with  the  specification  with  additional 
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explanation  supplied  below.  The  questions  below  are  only  suggestive  of  the  ones 
that  should  be  answered  in  the  Level  of  Detail  Guide.  Additional  questions  will 
need  to  be  answered  for  most  systems,  and  some  suggested  questions  may  not 
apply  to  a  given  system.  After  answering  such  questions,  and  analyst  must 
explain  the  directives  in  a  form  similar  to  Figure  18. 

5.6. 1.1  Discriminations  and  Perceptions.  The  Guide  must  define  the  level  of 
detail  by  answering  questions  such  as; 

a.  Observing  Gross  Indications.  If  a  technician  must  respond  to  a  gross 
indication  such  as  a  light  being  on  or  a  meter  being  out  of  an  acceptable  range  of 
values,  will  the  task  step  merely  name  the  indicator  or  meter  and  state  the  value 
to  be  observed  or  should  there  be  an  illustration  that  sho"’s  the  indicator  in  the 
"on"  state  or  the  meter  in  an  out-of-tolerance  condition? 

b.  Reading  Quantitative  Values.  When  a  technician  must  respond  to  a  pre¬ 
cise  value  on  a  meter  (plus  or  minus  some  tolerance),  will  the  meter  face  always 
be  illustrated?  Which  meters  will  be  treated  differently?  Will  some  meters 
require  special  instructions  on  how  they  are  to  be  read  (e.g. ,  how  to  make 
interpretations )  ? 

c.  Noting  Relative  Motion.  Will  instruments  be  used  to  detect  relative 
motion  between  components?  How  much  will  have  to  be  said  concerning  the  use 
of  these  instruments?  If  instruments  are  not  used,  how  much  should  be  said 
about  the  technician's  point  of  observation?  Will  the  illustrations  indicate  the 
direction  of  motion? 

d.  Reading  or  Interpreting  Oscilloscope  Patterns  and  Waveforms.  How 
will  standards  for  comparison  be  presented?  What  dimensions  of  the  waveforms 
will  be  specified?  How  much  will  be  said  about  the  appropriate  methods  for 
determining  amplitude,  frequency,  and  shape  of  the  waveforms? 

e.  Noting  Visually  Detectable  Physical  Defects.  Will  standards  for  com¬ 
parison  be  presented  or  will  it  be  assumed  that  these  judgments  will  be  mas¬ 
tered  in  training?  Will  illustrations  show  only  obviously  acceptable  and  obviously 
unacceptable  conditions,  or  will  various  degrees  of  marginally  acceptable  condi¬ 
tions  be  shown  and  evaluated? 

f.  Detecting  Presence  or  Absence  of  Sounds  and  Vibrations.  Will  the 
sounds  or  vibrations  be  characterized  in  words,  or  will  they  merely  be 
named?  Will  detection  of  vibrations  be  by  feel? 
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1.  DISCRIMINATIONS  AND  PERCEPTIONS  CRITICAL  TO  SUCCESSFIX  TASK  PERFORMANCE 

a.  Observing  Gross  Indications.  The  task  step  will  name  the  indicator 
and  will  state  the  condition  to  be  observed  (for  example,  a  light  on  or  off; 

a  motor  running  or  not  running).  The  illustration  will  depict  the  indicator's 
location;  wherever  practical  and  necessary  to  communicate  an  instruction,  the 
illustration  will  also  show  the  state  of  the  indicator. 

b.  Reading  Quantitative  Values.  The  task  step  will  state  a  range  of 
acceptable  values  by  naming  the  Inclusive  limits  of  the  range.  The  location 
of  the  indicator  (scale,  counter)  will  be  illustrated  (with  the  exception  of 
some  common  pieces  of  test  equipment  see  the  Support  Equipment  Guide). 
Counter  readings  will  not  be  illustrated.  Necessary  scale  reading  and  inter¬ 
polation  skills  are  assumed  to  be  present  in  the  user. 

c.  Noting  Relative  Motion.  When  relative  motion  is  an  Important  cue, 
the  task  step  will  describe  the  relevant  dimensions  of  motion  (direction 

and, or  rate)  of  objects  with  respect  to  one  another,  and  will  include  a  state¬ 
ment  of  the  observer's  position  relative  to  the  objects  whenever  position 
is  necessary  for  correct  interpretation  of  the  text  (e.g.,  a  fan  rotating 
clocki'ise  when  viewed  from  the  front).  Illustration  of  the  moving  components 
will  indicate  the  direction  of  motion  with  the  use  of  an  arrow  pointing  from 
each  object  along  its  path  of  motion. 

d.  Reading  or  Interpreting  Oscilloscope  Patterns  or  Waveforms.  The  task 
step  text  will  require  the  technician  to  compare  display  with  a  standard 
provided  in  the  illustration.  The  illustration  will  be  a  line  drawing  or 
rendering  of  the  nominal  expecteo  display,  with  the  frequency,  amplitude, 
and/or  shape  tolerance  range  indicated  with  dimension  lines,  and  a  statement 
of  the  tolerance  (e.g.,  "greater  than  10  divisions"). 


FIGURE  18.  Example  of  level  of  detail  guide. 
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g.  Discrimination  of  Pitch  or  Other  Characteristics  of  a  Sound.  In  what 
term  will  pitch  be  described?  In  what  terms  will  other  characteristics  of  sound 
be  described? 

h.  Discrimination  of  Odors.  How  will  significant  odors  be  described? 

5. 6. 1.2  Problem  Solving  and  Decision  Making.  The  Guide  must  define  the  level 
of  detail  by  answering  questions  such  as: 

a.  Selection  of  Appropriate  Next  Step  or  Task.  Will  guidance  be  provided 
for  each  decision  that  arises  ?  In  what  situations  will  the  next  step  or  task  not 
be  specified? 

b.  Performing  Calculations.  What  sorts  of  calculations  will  be  explained 
in  detail?  In  what  cases  will  tables  or  nomographs  be  substituted  for  each  cal¬ 
culation  ? 


c.  Exercising  Judgment.  Will  the  technician  be  required  to  make  judg¬ 
ments  without  the  aid  of  the  JPA?  When? 

d.  Conversion  of  Data  from  One  Form  to  Another.  Will  conversions  (e.g. , 
binary  to  decimal  or  Farenheit  to  Centigrade)  be  aided  by  tables  or  graphs? 

Will  complete  instructions  and  examples  accompany  any  tables  or  graphs  that 
are  presented? 

5.6. 1.3  Motor  Actions.  The  Guide  must  define  level  of  detail  by  answering 
questions  such  as; 

a.  Activating  Switches.  Will  the  desired  setting  for  the  switch  be  illus¬ 
trated  as  well  as  being  specified  in  the  text?  Will  the  location  of  the  switch  be 
illustrated,  described  in  the  text,  or  neither? 

b.  Adjusting  Continuous  and  Multiposition  Controls.  Will  the  desired  set¬ 
ting  for  the  switch  be  illustrated  as  well  as  being  specified  in  the  text?  Will  the 
location  of  the  switch  be  illustrated,  described  in  the  text,  or  neither?  Will  the 
direction  of  operation  be  specified  (e.g. ,  clockwise,  to  the  left)? 

c.  Performing  Coordinated  Gross  Bocfy  Movements.  Will  the  movements 
required  for  moving  and  positioning  hardware  items  be  described  or  merely 
named? 

d.  Performing  Actions  Requiring  Fine  Coordination.  Will  guidance  be 
provided  for  performing  actions  requiring  fine  coordination? 
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5.7  Performing  the  Task  Detail  Analysis.  The  Level  of  Detail  Analysis  described  in 
Section  5.6  provides  the  rules  for  "how  much  detail"  the  JPA  developer  must 
provide  in  the  task  steps.  The  Task  Detail  Analysis  discussed  here  will  con¬ 
sider  those  rules  in  establishing  for  each  specific  task  "what  must  be  done." 
Note  that  this  analysis  will  not  communicate  "how"  to  do  it  —  that  is  left  to  the 
JPA  developer  to  analyze  from  a  behavioral  approach  and  then  to  communicate 
"how  to"  to  the  user.  To  illustrate,  in  Figure  19,  Sheets  2  and  3,  the  analyst 
has  determined  the  task  details  that  must  be  covered  ly  the  JPA  developer  in 
Removing  and  Installing  Fuselage  Tank  Units.  In  Sheet  3  of  the  figure,  the  ana¬ 
lyst  describes  the  task  details  necessary  for  Follow-On  Maintenance  after  the 
tank  units  have  been  installed.  In  the  second  item  of  that  follow-on  maintenance, 
the  task  detail  analysis  has  determined  that: 

a.  The  access  panels  must  be  installed  after  the  tank  units.  Presume  that 
the  analyst  knows  from  the  Definitized  User  Profile  that  the  technician  will  not 
be  experienced  in  this  installation  and  the  Level  of  Detail  Analysis  indicates  that 
the  JPA  must  always  give  detailed,  well-illustrated  reassembly  procedures. 

The  Level  of  Detail  Guide,  for  example,  would  have  prescribed; 

Disassembly  and  Reassembly.  For  disassembly  and  reassembly 
(or  removal  and  installation)  the  task  step  will  always  provide  step- 
by-step  reassembly  procedures  and  illustrations  of  attaching  panels, 
hardware,  etc. ,  to  show  all  parts  as  seen  from  the  installer’s  position 
relative  to  the  equipment.  Assume  that  the  technician  is  familiar  with 
use  of  the  torque  wrench. 

b.  The  analyst  has  indicated  what  tasks  are  to  be  performed  (i.e. , 
"Engage  access  panel  screws"  and  later  "Perform  leak  test  of  fuel  tanks").  The 
JPA  developer  will  illustrate  and  explain  these  tasks  to  the  extent  that  the  task 
analyst  has  directed  in  the  Level  of  Detail  Guide,  The  analyst  must  make  cer¬ 
tain  that  every  non-troubleshooting  task  identified  in  the  TIM  for  inclusion  in  a 
JGM  has  been  analyzed  to  determine  the  cues  for  each  task  step,  the  precondi¬ 
tions  for  task  performance,  the  steps  that  are  necessary  for  successful  task 
completion  (including  performance  standards  and  keyed  locator  illustrations ) , 
identification  of  follow-on  tasks,  and  other  data  that  is  important  for  the  JGM 
developer  to  know.  Most  of  the  task  step  detail  analysis  is  in  the  actual  writing 
of  task  step  details,  discussed  in  the  following  paragraphs. 

5.7. 1  Writing  Task  Analysis  Worksheets.  The  contractor  shall  record  the 
results  of  the  analysis  of  each  task  on  Task  Analysis  Worksheets,  one  set  for 
each  task.  The  worksheets  must  contain  all  of  the  information  required  by  the 
specification  and  the  general  format  of  the  worksheets  must  be  similar  to  that 
in  Figure  19.  Legibility,  completeness,  and  accuracy  are  the  primary  require¬ 
ments  for  an  acceptable  task  analysis  worksheet.  The  first  step  in  preparing  a 
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FIGURE  19.  Example  of  task  analysis  worksheets  (sheet  1  of  4). 
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FIGURE  19.  Example  of  task  analysis  worksheets  (sheet  2  of  4). 
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FIGURE  19,  Example  of  task  analysis  worksheets  (sheet  3  of  4). 
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FIGURE  19.  Example  of  task  analysis  worksheets  (sheet  4  of  4). 
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worksheet  is  to  fill  in  all  of  the  identifying  and  administrative  data  (circled  item 
numbers  1  to  6  on  Figure  19)  and  Input  Conditions  information  (items  7  to  11), 
as  indicated  on  the  form. 

The  analyst  can  determine  the  Required  Conditions,  item  7,  for  the  task  by  learn¬ 
ing  the  interrelationships  between  tasks  from  SMEs  and  from  early  development 
of  typical  or  preliminary  tasks.  Early  in  the  MTI&A  process,  the  analyst  will 
begin  to  find  common  or  typical  tasks  that  will  be  required  as  preliminary  to  or 
part  of  other  tasks.  To  the  extent  possible,  the  analyst  should  try  to  determine 
early  in  the  analysis,  which  are  the  common,  often  used  tasks.  Generating  the 
worksheets  for  common  tasks  early  and  knowing  their  content  will  simplify  the 
organization  and  development  of  the  Required  Conditions  entries  for  all  other 
worksheets.  For  example,  if  the  "Removal  of  the  Left  and  Right  Main  Landing 
CJear  Actuator  Valves  "  is  a  procedure  that  must  precede  many  other  mainte¬ 
nance  tasks,  it  is  very  helpful  to  complete  the  worksheet  on  that  task  early  so 
that  the  analyst  knows  where  it  begins  and  ends  when  considering  other  tasks. 

The  analyst  should  refer  to  LSAR  Data  sheet  C  or  D,  to  find  the  number  of 
persons  required  in  performance  of  the  task  (worksheet  item  8),  W^hen  using 
such  input  data,  the  analyst  must  verify  that  the  task,  as  performed  on  the 
real  equipment,  can  be  performed  with  the  personnel  indicated  on  the  data 
sheets.  The  analyst  should  note  the  importance  of  communication  and  coordi¬ 
nation  between  members  of  a  team  performing  a  task. 

The  analyst  should  refer  to  Data  sheet  E  or  to  the  Support  and  Equipment  Sum¬ 
mary  for  a  listing  of  the  items  of  support  and  test  equipment  required  (worksheet 
item  9)  and  Supplies  (item  10),  for  each  task.  The  contractor  should  make  cer¬ 
tain  that  the  support  equipment  listed  in  the  task  analysis  worksheet  agrees  with 
the  LSAR  data,  including  part  numbers,  description,  etc.  Much  of  the  data  in 
the  worksheets  may  be  invalid  if  the  wrong  model  or  type  of  support  equipment 
has  been  used  in  task  step  details. 

The  analyst  should  ensure  that  all  conditions  which  may  affect  the  safety  of  per¬ 
sonnel  or  equipment  have  been  considered  and  listed  under  item  11  of  the  work¬ 
sheet.  Overall  notes,  cautions,  and  warnings  shall  be  included  under  this  item, 
even  though  they  will  also  be  repeated  just  preceding  the  task  step  to  which  they 
apply.  To  ensure  that  all  such  data  are  included,  the  analyst  should  consult 
subject  matter  experts  who  may  be  responsible  under  the  contract  for  hazard 
identification  if  MIL-STD-882,  System  Safety  Program  Requirements,  is  in¬ 
voked.  Evaluation  of  component  fault  hazards,  their  causes,  and  hazardous 
effects  is  important  data  that  must  be  investigated  and  included  in  the  work¬ 
sheets.  The  analyst  should  examine  LSAR  Data  sheet  D  for  the  safety  hazard 
level  code.  If  no  formal  safety  requirements  are  included  in  the  contract,  the 
analyst  should  seek  out  such  information  from  subject  matter  experts. 
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The  heart  of  the  task  analysis  process  is  in  the  writing  of  task  step  details  for 
worksheet  items  12,  13,  and  14  by  the  MTI&A  analyst.  The  description  of  each 
step  must  communicate  enough  detail  and  guidance  so  that  the  JPA  developer  will 
understand  the  behaviors,  cues,  and  technical  information  the  user  needs  to  per¬ 
form  the  task  successfully. 

Each  task  must  be  analyzed  to  define  in  precise  terms  what  the  users  will  see 
or  detect  (behavioral  cues)  and  what  their  responses  must  be  to  accomplish  the 
task  objectives.  To  ensure  a  precise  understanding  of  all  the  task  conditions, 
cues,  responses,  and  objectives,  the  analysts  must  put  themselves  in  the  role 
of  the  technician  trying  to  perform  the  task.  The  analysts'  aim  is  to  determine 
the  optimum  way  to  perform  each  task  step  and  to  ensure  that  all  of  the  cues  to 
which  the  user  must  respond  have  been  communicated. 

A  cue  is  simply  a  signal  for  action  by  the  technician.  It  can  be  a  condition  ("If 
the  alarm  light  is  on"),  an  event  or  situation  ("When  the  system  is  ready"),  or 
the  completion  of  the  preceding  task  step.  The  analyst,  then,  must  organize  the 
cues  in  optimum  sequence  that  will  start  the  task,  proceed  through  the  necessary 
performance  steps,  and  then  end  the  task.  In  analyzing  the  technical  detail  in 
conjunction  with  behavioral  cues  and  responses  the  analyst  should  ask; 

a.  What  conditions  exist  that  make  it  possible  for  the  procedure  to  start 
(initiating  cues )  ?  For  example; 

1.  Is  removal  of  the  aircraft  fuel  tanks  a  task  that  can  be  performed 
at  Intermediate  maintenance  level  safely? 

2.  Is  the  aircraft  safe  for  maintenance? 

3.  Has  the  aircraft  been  defueled? 

4.  Has  it  been  drained  and  purged? 

5.  Have  preparatory  tasks  (from  other  procedures)  been  performed 
(e.g. ,  removal  of  access  panels)? 

b.  What  are  the  various  technician  responses  that  trigger  the  next  cue? 
Usually  the  completion  of  the  preceding  step  triggers  the  next,  in  a  chain  of  task 
steps.  In  the  body  of  task  steps,  the  analyst  must  consider  the  behavioral  dis¬ 
criminations  and  perceptions,  problem  solving  and  decisions,  and  motor  actions, 
described  in  paragraphs  5.6. 1.1,  5. 6.1. 2,  and  5.6. 1.3.  Each  of  those  ques¬ 
tions  must  be  analyzed  to  ensure  the  task  steps  are  complete.  In  addition  to 
these  discriminations  and  perceptions,  the  analyst  must  determine  through  in¬ 
quisitive  research  whether  there  is  a  better  technique  or  a  special  trick  that 
will  help  the  user.  For  example,  "Would  loosening  the  access  plate  for  the 
clutch  assembly  give  the  technician  better  access  to  the  gear  train?"  or 
"Would  the  use  of  a  printed  circuit  board  extractor  eliminate  steps  d  and  e?" 


c.  What  cues  signal  the  end  of  the  task?  A  common  problem  in  MTI&A  is 
to  miss  or  omit  final  wrapup  steps  because  they  are  so  obvious  (e.g. ,  "Discon¬ 
nect  test  equipment,"  or  "Tighten  panel  screws").  Because  these  ending  steps 
are  often  critical,  the  analyst  must  ensure  that  accurate  cues  are  provided  to 
the  JPA  developer. 

It  is  important  to  reiterate  the  need  for  validation  of  task  steps  through  perform¬ 
ance  by  the  analyst  or  by  observation  of  performance  by  a  typical  user.  The 
analyst  should  ensure  the  validity  and  completeness  of  LSA  information  by  actual 
testing  with  such  typical  questions  as; 

a.  Is  there  any  cue  or  action  that  must  precede  this  step? 

b.  Are  there  too  many  cues  in  the  task  step? 

c.  Is  that  step  always  performed  this  way? 

d.  Is  there  an  alternative  to  this  step? 

e.  Is  the  observed  behavior  of  the  tested  user  more  typical  than  assumed 
in  the  LSA  data? 

f.  Is  this  the  quickest  sequence  of  task  steps  possible? 

g.  Have  all  available  support  equipment  been  fully  utilized  in  task  steps? 

As  described  in  5. 1.2,  LSAR  Data  sheet  D  provides  a  narrative  description  of 
each  maintenance  task  (e.g. ,  replace  tank  cover  gasket),  as  well  as  description 
of  the  steps  necessary  to  accomplish  the  task.  If  the  analyst  verifies  the  cues 
and  behavioral  responses  described  in  sheet  D,  its  data  pi  ovides  an  excellent 
input  to  task  analysis,  as  well  as  the  descriptions  of  the  actual  steps  necessary 
to  accomplish  the  task,  for  example: 

a.  Remove  gasket  from  around  tank  cover  mounting  surface. 

b.  Use  knife  to  lift  gasket  from  groove. 

c.  Remove  old  adhesive  using  cleaning  solvent  and  clean. 

The  data  may  not  be  in  perfect  form  and  the  analyst  may  wish  to  improve  or 
modify  the  task  step  wording,  as  appropriate.  For  example,  investigation  may 
indicate  that  step  b  should  precede  step  a  and  that  another  tool  would  be  safer 
and  more  effective  than  a  knife.  The  analyst  must  also  consider  data  from  tech¬ 
nical  manuals  and  other  sources,  as  a  check  on  questionable  LSA  task  step  in¬ 
formation.  If,  however,  the  LSAR  data  are  found  to  be  technically  complete  and 
accurate,  the  analyst  can  significantly  cut  the  MTI&A  effort  by  depending  on  it. 
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5. 7. 1.1  Hands-on  Equipment  Analysis.  The  equipment  is  the  only  completely 
reliable  source  of  information  about  itself.  As  the  development  of  task  steps  and 
step  description  for  the  worksheets  progresses,  the  analyst  must  gain  regular 
hands-on  access  to  the  system  or  equipment.  The  surest  way  to  ensure  accuracy 
and  completeness  is  to  eliminate  theorizing  and  guesswork  actually  perform¬ 
ing  tasks  such  as  making  checks  with  the  actual  test  equipment,  disassembling 

a  hard-to-reach  assembly,  or  going  through  all  the  steps  of  a  complex  align¬ 
ment.  The  hands-on  effort  gives  the  analyst  confident  familiarity  with  the  equip¬ 
ment,  which  usually  is  reflected  in  better  task  analysis  and  decreased  develop¬ 
ment  time  for  MTI&A.  Later  in  the  analysis  process,  of  course,  the  analyst 
must  validate  all  of  the  worksheet  data  and  other  MTI&A  products  on  the  actual 
equipment.  The  analyst  will  find  validation  a  much  simpler  process  if  the  task 
worksheet  data  have  been  tried  out  on  the  equipment  all  during  development. 

5. 7. 1.2  Level  of  Detail  in  Step  Descriptions.  The  analyst  should  ensure  that  for 
each  task  and  subtask  the  worksheet  includes  only  the  simplest,  briefest,  and 
most  straightforward  and  efficient  step  descriptions.  The  level  of  detail  of  the 
worksheet  step  descriptions  shall  be  consistent  with  the  level  recommended  in 
Figure  19,  Sheet  2  Item  14.  If  it  is  too  brief,  it  will  require  the  JPA  developer 
to  re-examine  the  data  thereby  repeating  the  research  efforts  of  the  task  analyst. 
If  it  is  more  detailed  than  the  sample,  the  analyst  will  have,  in  effect,  written 
the  JPA  procedures  and  that  is  not  the  purpose  of  the  MTI&A  process  or  the 
function  of  an  analyst.  The  data  called  for  in  the  worksheet  is  the  keystone  of 
the  MTI&A,  Step  descriptions  must  include  all  elements  of  the  procedure  and 
identify  all  of  the  cues  available  to  the  user  and  all  of  the  responses  the  user 
must  make.  Given  this  information,  the  JPA  developer  can  prepare  procedures 
which  focus  on  the  cues  available  to  the  technician  and  explain  the  responses 
which  must  be  made.  The  task  analyst's  job  is  to  make  certain  that  all  of  the 
information  required  to  write  the  procedure  in  accordance  with  the  specification 
is  in  the  data  base.  The  analyst  must  imagine  how  the  technician  will  perceive 
the  real  equipment  and  relate  to  it  using  the  JPA.  In  writing  step  descriptions, 
the  analyst  must  mentally  assume  the  place  of  the  maintenance  technician  who 
will  perform  the  task  in  the  field.  The  analyst  must  visualize  performance  of 
the  task,  conceptualize  the  JPA  that  will  be  prepared  to  meet  the  stated  require¬ 
ments,  and  then  judge  whether  the  needed  data  are  in  the  data  base.  It  is  much 
better  to  err  in  favor  of  providing  more  data  than  the  JPA  developer  needs  than 
the  costly  problem  that  would  develop  if  there  were  not  enough  data.  Finally, 
any  missing  information  must  be  obtained  and  included  to  complete  the  task  data 
base. 

5. 7. 1.3  Illustrations.  The  analyst  must  attach  to  each  worksheet,  any  and  all 
illustrative  data  such  as  engineering  drawings,  diagrams,  sketches,  photographs, 
copies  of  pages  from  commercial  manuals,  or  combinations  of  these  that  were 
used  in  compiling  the  task  detail  analysis  and  worksheets.  The  analyst  should 


provide  sketches  of  settings,  frfiysical  locations,  etc. ,  that  are  important  in 
understanding  the  step  description.  The  analyst  should  annotate  each  item  with 
callouts,  lines,  notes,  sketches,  etc.,  as  appropriate.  Such  data  maybe  applied 
by  hand,  as  long  as  it  is  neat  and  legible.  Each  worksheet  illustration  package 
should  be  preceded  by  a  listing  of  illustrations  that  the  analyst  has  compiled  to 
si^port  the  task.  Most  are  normal  outgrowths  of  engineering  documentation 
except  for  analyst's  sketches  and  are  an  excellent  asset  to  the  analyst  to  com¬ 
municate  technical  information  and  graphic  detail  to  the  JPA  developer.  Most 
equipment  manufacturers  can  be  expected  to  produce  as  a  part  of  their  design 
and  fabrication  process,  a  complete  set  of  drawings  for  use  in  developing  a 
prototype.  Topically  an  engineering  drawing  package,  which  will  be  available  to 
the  analyst,  will  consist  of  the  following: 

a.  Installation  Drawings.  An  installation  assembly  drawing.  Figure  20, 
illustrates  the  installed  or  assembled  portion  of  an  item  or  items  relative  to  its 
supporting  structure  or  to  associated  items.  An  installation  control  drawing. 
Figure  21,  supplies  information  on  the  item  in  terms  of  area,  weight,  access 
clearances  and  any  attachments  required  for  installation  or  proper  operation  of 
the  item.  The  analyst  is  using  the  sample  installation  drawings  to  show  the  JPA 
developer  the  position  of  the  Printer  in  the  trailer  with  notations  about  its  final 
position.  The  analyst  has  also  included  the  installation  control  drawing  to  por¬ 
tray  installation  details  and  physical  mounting  information  for  use  in  future  cre¬ 
ation  of  JPA  artwork  on  the  unit.  Note  the  neat,  handwritten  notes  by  the  analyst 
to  indicate  important  features  of  the  drawings.  Such  installation  drawings  are 
normal  outputs  of  the  contractor's  system  engineering  or  facility  design  function. 
The  analyst  need  only  add  important  task  notes  and  attach  to  the  Task  Analysis 
Worksheet.  These  two  installation  drawings  may  be  copied  and  used  over  and 
over  again  (each  time  with  notations  peculiar  to  the  specific  task).  Do  not  refer 
to  such  drawings  from  one  Worksheet  to  another  because  it  creates  total  confu¬ 
sion  to  the  analyst,  to  government  reviewers,  contractor  SMEs  and  to  the  JPA 
developer. 

b.  Interface  Control  Drawings.  Interface  control  drawings  such  as  that 
shown  in  Figure  22  illustrate  physical  and  functional  interface  requirements  of 
an  item  which  will  affect  the  design  or  operation  of  associated  or  connecting 
items.  The  analyst  should  review  this  type  of  drawing  and  use  it  where  approp¬ 
riate  to  convey  any  of  the  physical  information  it  depicts.  Note  that  the  analyst 
is  not  using  the  drawing  to  show  interface  requirements  of  connecting  items  but 
rather  as  an  available  type  of  data,  which  when  clearly  annotated  with  large, 
legible  notes  is  a  vehicle  for  transmitting  data. 

c.  Schematic  Drawings.  Schematic  drawings  such  as  that  shown  in  Figure 
23  enable  the  analyst  to  illustrate  by  means  of  notations  on  an  existing  functional 
diagram  information  pertinent  to  the  particular  task.  The  analyst  has  used  the 
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FIGURE  20,  Sample  installation  drawing. 


FIGURE  21.  Sample  installation  control  drawing. 
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FIGURE  23.  Sample  schematic  diagram 


hybrid  logic  schematic  in  the  sample  as  a  vehicle  to  show  various  input  and  out¬ 
put  test  data  which  will  support  a  task  step.  The  type  of  data  shown  in  this 
sample  is  most  effectively  used  in  troubleshooting  analysis  described  later.  It 
also  makes  available  to  the  JPA  developer  data  concerning  physical  test  points 
(e.g.  ,  for  checking  the  various  input  and  output  voltages  with  an  oscilloscope). 

In  the  sample,  the  analyst  has  provided  additional  data,  at  the  bottom  of  the  draw¬ 
ing,  on  what  to  test  at  various  pins.  The  analyst  should  siyiply  and  annotate  only 
those  schematics  which  are  necessary  to  support  the  maintenance  tasks.  The 
analyst  should  make  certain  that  all  pertinent  input  or  output  waveforms  and 
voltage  and  resistance  measurements  are  listed  at  connectors  and  terminal 
boards.  Also  all  test  point  locations  and  test  equipment  connection  points  should 
be  included  on  drawings  where  available  (the  analyst  should  add  such  data  to  pre¬ 
liminary  schematics  if  necessary). 

d.  Interconnection  and  Wiring  Diagrams.  Interconnection  diagrams.  Fig¬ 
ure  24,  or  wiring  diagrams.  Figure  25,  are  typical  engineering  development 
drawings  which  can  be  used  by  the  analyst  to  illustrate  internal  and  external 
electrical  connections  or  as  a  vehicle  for  other  data,  as  in  Figure  25.  The  ana¬ 
lyst  should  show  specific  test  points,  and  input  and  output  voltage  and  waveform 
measurements  and  make  sure  all  component  parts  are  properly  identified  by 
reference  designation,  unit  or  -^roup  symbol  numbers  or  location. 

e.  Logic  Diagrams.  Logic  diagrams  shown  in  Figure  26,  are  usually  used 
by  the  analyst  in  troubleshooting  analysis,  described  later.  In  Performance 
Analysis,  the  analyst  can  use  these  diagrams  to  show  pertinent  input  and  output 
test  points  and  values.  Associated  timing  diagrams  should  be  supplied  when  they 
aid  in  the  performance  analysis  and  checkout  summary.  Notations  should  be 
made  as  neatly  and  legibly  as  shown  in  the  sample. 

f.  Mechanical  Schematic.  Mechanical  schematics  shown  in  Figure  27, 
illustrate  the  operational  sequence  or  arrangement  of  mechanical  device(s). 

The  analyst  can  use  this  type  of  existing  engineering  drawing  to  show  all  mechan¬ 
ical  parts  of  an  assembly  and  to  properly  identify  them  by  name  or  function. 

(Make  certain  that  all  gear  ratios  and  rotational  directions  are  clearly  shown, 
when  it  is  pertinent  to  the  task.) 

g.  Elevation  Drawings.  Elevation  drawings.  Figure  28,  depict  vertical 
projections  of  structures  or  profiles  of  equipment  such  as  aircraft  or  electron¬ 
ics  systems.  They  show  configuration,  shapes  and  sizes  of  features,  compart¬ 
ments,  location  and  arrangement  of  machinery  or  fixed  equipment.  They  are 
therefore  a  valuable  aid  to  the  analyst  in  identifying  equipment  or  assembly 
geography. 
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FIGURE  24,  Sample  interconnection  diagram 


FIGURE  25.  Sample  connection  or  wiring  diagram 


FIGUR  E  26.  Sample  logic  diagram 


FIGURE  27.  Mechanical  schematic  diagram. 
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FIGURE  28.  Sample  elevation  drawing. 


h.  Assembly  Drawings.  Assembly  drawings,  such  as  shown  in  Figure  29, 
illustrate  the  assembled  relationship  of  two  or  more  parts,  a  combination  of 
parts  and  subassemblies,  or  a  group  of  assemblies  required  to  form  an  assem¬ 
bly  of  higher  order.  Assembly  drawings  can  be  presented  in  orthographic  draw¬ 
ing  form,  photo-assembly  form  using  halftone  (screened)  photographs,  or  in 
exploded  assembly  form  utilizing  either  isometric  or  perspective  drawing  tech¬ 
niques.  The  analyst  should  use  assembly  drawings  only  if  they  contain  sufficient 
detail  or  detailed  views  to  show  proper  relationships  between  subordinate  assem¬ 
blies  and/or  parts  that  support  Worksheet  details. 

i.  Component  Part  Drawing.  Component  part  drawings  are  engineering 
drawings  that  define  an  item  and  assign  a  part  or  control  number  to  identify  its 
configuration.  Although  at  O  and  I  levels,  analysts  may  not  need  to  use  part 
drawings,  many  show  details  that  are  helpful  to  the  JPA  developer. 

j.  Miscellaneous  Drawings.  Figures  30  and  31  illustrate  other  fypes  of 
engineering  drawings  which  will  augment  the  Task  Analysis  Worksheet  package. 
The  analyst  should  review  all  available  drawings  of  this  type  and  annotate  those 
that  illustrate  pertinent  data  with  notes,  callouts,  part  numbers,  descriptive 
data,  etc. ,  if  it  will  improve  the  understandability  of  the  worksheet  package. 

k.  Descriptive  and  Supplemental  Data.  When  a  suitable  engineering  draw¬ 
ing  package  is  not  available  or  when  the  illustrative  data  package  does  not  fully 
support  the  task  worksheet,  the  analyst  must  supplement  or  provide  the  data  in 
other  forms.  This  supplemental  data  can  be  in  the  form  of  Polaroid  or  35  mm 
photographs  of  suitable  size  and  quality  that,  when  properly  annotated,  suitably 
portray  the  equipment.  Rough,  hand-drawn  sketches,  similar  to  that  illustrated 
in  Figure  32,  can  be  prepared  inexpensively  the  analyst  or  with  some  illus¬ 
trator  support.  Care  should  be  taken  in  preparing  such  sketches  to  ensure  that 
all  details  are  clearly  defined,  that  the  sketches  are  prepared  in  proper  perspec¬ 
tive  for  maximum  usability,  and  that  the  line  weight  of  drawings  is  heavy  enough 
to  produce  clear,  legible  copies  when  reproduced  with  standard  office  type  copi¬ 
ers.  Additional  data  to  support  the  worksheet  can  be  obtained  from  commercial 
handbooks,  brochures,  and  catalogues.  A  typical  illustrative  package  supplied 
with  the  Task  Analysis  Worksheet  to  illustrate  an  engine  fuel  control  assembly 
for  the  JPA  developer  is  shown  in  Figure  33.  Note  that  in  Figure  33,  the  analyst 
has  provided  the  JPA  developer  with  a  trail  through  a  number  of  related  photo¬ 
graphs  and  illustrations  culled  from  various  sources  with  arrows  and  references 
(detail  A,  detail  B,  etc.). 
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FIGITJ  E  29.  Sample  as!5emblv  drawinj?. 


FKJI'RF;  .to.  Sample  illustrated  assembly  clrawing. 
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FIGURE  31.  Sample  test  setup  diagram 
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FIGirRE  32.  Sample  analyst  rough  sketch. 


FIGURE  33.  Sample  illustration  package  for  task  analysis  worksheet. 


MICROCOPY  RtSOLUTION  TtST  CHART 


Each  illustration,  data  sheet,  or  procedure  should  have  a  unique  task  analysis 
worksheet  identification  with  the  number  noted  on  the  worksheet.  Below  is  a 
typical  checklist  of  guidelines  to  aid  the  analyst  in  preparing  and  checking  on  the 
completeness  and  suitability  of  die  illustrations  being  supplied  as  part  of  the 
illustrative  package. 


YES 

NO 

N/A 

1. 

Subject  matter  clearly  and  correctly  portrayed. 

2. 

Subject  matter  la  in  proper  relation  to  other  aasembliea  and 
viewed  from  angle  and  perepective  of  the  technician. 

3. 

Official  nomenclaturee  and  reference  designators  agree  with 
the  source  data. 

4. 

Illustration  depicts  the  correct  maintenance  technique  and 
operation  of  the  assembly  under  test. 

5. 

If  halftones  are  used,  th^  are  clear  enou^  for  an  illustrator 
to  develop  a  detailed  view  of  the  assembly  or  component. 

6. 

No  diagrams  are  included  that  arc  not  of  use  in  JPA  develop¬ 
ment. 

7. 

All  parts  required  for  JPA  development  are  included  and 
identified  properly. 

8. 

All  analyst  annotations  are  legible. 

9. 

All  drawings  Included  with  the  worksheet  package  have  been 
annotated  to  explain  their  usefulness  to  the  JPA  developer. 

5. 7. 1. 4  Follow-on  Maintenance.  The  analyst  must  identify  all  maintenance 
actions  which  must  be  performed  after  the  subject  task.  Some  tasks  are  not 
complete  work  units  in  themselves.  When  the  goal  of  the  task  is  achieved,  the 
tasks  required  to  return  the  system /equipment  to  operational  readiness  or  safe 
condition  after  completion  of  the  task  shall  be  listed  in  this  item. 

5.8  Troubleshooting  Task  Analysis.  Since  this  phase  of  task  analysis  is  the  most 
demanding,  it  requires  the  most  qualified  people  (anafysts)  and  dedicated  support 
to  the  analysts  (subject  matter  experts,  equipment  availability,  management 
siqiport,  etc.).  Prc^erly  planned,  siqiported,  and  carried  out,  this  phase  can 
produce  a  cost-efficient,  complete,  and  accurate  troubleshooting  data  base  that 
will  provide  the  user  with  useful,  effective  Logic  Tree  Troubleshooting  Aid 
JPAs  or  other  type  manuals,  as  appropriate.  Aided  fcy  LSAR  data,  and  previ¬ 
ously  developed  MTI&A  products,  the  TIM,  the  Definitized  User  Profile,  the 


Support  Equipment  Guide,  and  the  Level  of  Detail  Guide  the  analyst  must  perform 
a  Performance  Analysis  and  a  Failure  Mode  and  Fault  Symptom  Analysis.  The 
products  of  these  troubleshooting  analyses  are  as  follows: 


a.  Checkout  Summary 

b.  Fault  Si^mptom  List 

c.  Action  Trees 

5. 8. 1  Overview.  The  analyst  begins  the  analysis  and  definition  of  checkout  and 
troubleshooting  tasks  by  examining  the  TIM  for  all  cells  coded  as  OL,  IL,  or 
BL.  These  codes  indicate  that  checkout  and  troubleshoot  tasks  have  been  identi¬ 
fied  for  the  equipment  component  and  it  is  a  candidate  for  checkout  or  trouble¬ 
shooting  at  O  or  I  level,  or  at  both  levels  (B).  The  letter  L  indicates  that  the 
checkout  or  troubleshooting  task  will  be  developed  for  the  LTTA  manual.  In  the 
Performance  Analysis,  the  analyst  must  identify  all  of  the  design  functions  of 
the  subsystems  and  equipment,  and  establish  the  checks  that  can  determine  if 
these  functions  are  performing  normally.  The  performance  analysis  also 
establishes  the  measurable  parameters  associated  with  each  function  and  each 
component  thgt  contributes  to  that  function.  Performance  parameters  are  the 
range  of  acceptable  values  that,  when  measured,  indicate  whether  or  not  the 
component  (subsystem,  equipment,  assembly,  part)  is  operating  satisfactorily. 
The  results  of  this  analysis  are  recorded  on  a  Checkout  Summaiy,  Figure  34, 
which  becomes  the  basis  for  later  development  of  checkout  procedures  by  LTTA 
preparers.  (Checkout  procedures  in  the  LTTA  are  used  to  test  whether  the 
components  of  the  system  are  functioning  properly  or,  if  not,  are  causing  fault 
symptoms. )  Next,  with  the  aid  of  Data  sheet  B,  the  analyst  performs  a  failure 
mode  and  fault  s}rmptom  analysis  on  each  component  of  the  system  identified  in 
the  TIM  for  checkout  and  troubleshooting  tasks.  The  fault  symptom  analysis 
identifies  the  ways  in  which  each  component  or  function  can  fail  (its  failure 
modes)  and  cause  a  fault  and  a  related  fault  symptom.  This  analysis  produces 

a  list  of  fault  symptoms  for  each  failure  mode.  The  final  phase  of  troubleshoot¬ 
ing  task  analysis  is  the  development  of  an  Action  Tree  (AT)  for  each  of  the  fault 
symptoms  on  the  list. 

5.8.2  Accomplishing  Performance  Analysis 

5. 8.2. 1  Source  Data.  The  analyst  will  depend  on  a  number  of  data  sources  for 
troubleshooting  task  analysis,  but  few  are  as  important  as  solid  understanding  of 
the  theory  of  (deration  of  the  system,  at  and  above  the  pertinent  level  of  repair. 
The  data  sources  for  performance  analysis  will  focus  on  those  that  permit  the 
analyst  to  learn  the  functional  interrelationships  of  system  components,  such  as 
theoiy  of  operation  descriptions  and  diagrams  in  the  following. 
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FIGURE  34.  Example  of  checkout  summary. 
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a.  Existing  Technical  Literature  —  Contractor  SME  (engineers,  LSA  spe¬ 
cialists,  etc.)  should  be  able  to  provide  such  technical  literature  in  the  form  of 
commercial  operation  and  maintenance  manuals,  or  if  the  equipment  has  been 
previously  procured  for  military  use.  Air  Force  Technical  Orders,  Army  Tech¬ 
nical  Manuals,  etc.  If  the  system  employs  equipment  or  major  assemblies 
manufactured  by  other  companies,  commercial  manuals  are  usually  packed  with 
each  unit  shipped  to  the  prime  contractor.  If  not,  the  analyst  should  request 
the  contractor  purchasing  agent  to  request  or  purchase  commercial  manuals. 
MIL-spec  manuals  often  provide  the  analyst  with  greater  detail,  so  it  is  helpful 
to  query  the  manufacturer  to  determine  if  a  military  manual  has  been  developed 
on  the  component.  If  so,  it  can  be  ordered  through  your  contracting  office  or 
technical  library. 

b.  Functional  Block  and  Schematic  Diagrams  —  If  the  system /equipment 

is  imder  development  and  no  technical  literature  exists,  the  analyst  should  obtain 
electronic  and  mechanical  block  diagrams  that  show  the  organization  and  inter¬ 
relationships  of  units  from  the  design  engineering  personnel  or  from  the  manu¬ 
facturer.  Start  with  diagrams  used  in  catalogs,  data  sheets,  proposals,  etc. 

For  example,  many  technical  proposals  contain  such  drawings  showing  the  sys¬ 
tem  components  and  their  inputs  and  outputs.  Engineering  design  usually  begins 
with  sketched  block  diagrams  and  schematics  outlining  the  equipment  hierarchy. 
Figure  35  is  a  sample  of  the  system  hierarchy  portrayed  in  a  functional  block 
diagram. 


c.  Other  Data  —  The  analyst  will  also  need  more  detailed  information  in 
order  to  understand  the  system,  such  as  mechanical  layout  diagrams,  wiring 
lists,  written  functional  descriptions,  circuit  descriptions,  and  similar  data 
describing  signal  flow,  interdependencies,  operation,  and  performance  parame¬ 
ters.  Most  of  this  information  is  generated  in  some  form  by  engineers  to  explain 
to  other  supporting  departments  (logistics,  manufacturing,  etc.)  the  makeup  of 
the  hardware.  Consult,  for  example,  functional  descriptions  in  purchasing  spe¬ 
cifications  that  are  written  to  procure  vendor  equipments  or  assemblies.  Many 
purchased  items  such  as  printed  circuit  boards,  power  supplies,  and  mechanical 
assemblies  are  selected  from  company  catalogs  that  contain  descriptions,  dia¬ 
grams,  and  test  data. 

5. 8.2.2  Learning  the  System  Functional  Operation.  The  anafyst  must  become 
familiar  with  all  of  the  source  data  and  quickly  determine  weaknesses  and  data 
gaps,  if  there  are  aiQr.  If  the  data  are  inadequate  or  unreliable,  or  if  the  analyst 
is  doing  performance  analysis  on  a  developing  system  with  little  formal  data,  it 
will  be  necessary  to  learn  the  system  or  equipment  functions  by  other  means.  If 
technical  data  exist  on  hardware  that  has  similar  functions  or  components,  the 
analyst  should  assemble  data  on  and  study  those  parts  that  are  like  the  subject 
equipment  and  develop  the  functional  interrelationships  for  analysis  purposes  by 
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FIGUR  E  35.  Sample  system  block  diagram  for  use  in  performance  analysis 


assembling  and  studjying  engineering  drawings  or  sketches  on  new,  undocumented 
hardware.  After  that,  the  analyst  must  complete  the  learning  phase  by  interview 
and  consultations  with  subject  matter  experts  and  so  gain  the  knowledge  to  pre¬ 
pare  a  complete  Checkout  Summary,  a  Fault  Symptom  List,  and  complete  Action 
Trees, 

5. 8. 2. 3  The  Performance  Analysis  Process.  The  performance  anafysis  is 
developed  from  the  energy  flow  diagrams,  functional  block  diagrams,  schematics, 
and  other  collected  source  data  that  depict  the  functional,  organizational  hierarchy 
of  the  system  and  the  interrelationships  among  all  components.  The  analyst 
should  assemble  all  such  drawings  until  all  maintenance  significant  components 
(significant  at  Organizational  or  Intermediate  level,  as  appropriate)  in  the  entire 
system  or  equipment  are  represented.  Make  certain  by  checking  off  each  TIM 
component  to  show  that  there  is  coverage  for  that  item  at  the  pertinent  functional 
level.  If  you  have  each  assembly  on  the  block  diagram  checked  against  the  TIM, 
you  are  certain  of  a  complete  functional  picture.  At  each  new  level  of  subdivi¬ 
sion,  all  parts  or  assemblies  must  be  accounted  for  on  the  drawings  and  checked 
against  the  TIM.  Make  certain  that  all  the  components  related  to  cells  of  the 
TIM  that  are  marked  for  OL,  IL,  or  BL  can  be  identified  on  the  assembled  draw¬ 
ings.  For  each  such  TIM  component,  annotate  the  drawing  to  show  the  measur¬ 
able  performance  parameter  for  that  component  (such  as  24  Vdc;  ±1.2  Vdc,  or 
horizontal  scan  »  5  inches  ( ±  .15  inch).  Figure  23  is  a  diagram  that  the  analyst 
has  researched  and  neatly  annotated  to  show  the  performance  parameters  of  each 
functional  block. 

The  analyst  checks  the  accuracy  of  these  aimotated  performance  parameters 
testing  them  with  appropriate  test  equipment  on  the  actual  system  hardware  or 
by  visualizing,  etc. ,  as  the  check  requires.  After  each  is  tested  and  if  neces¬ 
sary  corrected,  the  analyst  has  a  complete  set  of  source  data  drawings  which 
contain,  for  each  TIM  cell  marked  for  Checkout/Troubleshoot,  a  measurable  or 
observable  parameter  consisting  of  input  or  output  measurements,  observable 
indications,  panel  readings,  etc.  The  analyst  should  include  in  the  annotations 
information  concerning  test  equipment  to  be  used  or  other  methods  of  observa¬ 
tion.  These  drawings  will  be  used  as  follows: 

a.  To  develop  the  Checkout  Summary 

b.  To  aid  the  analyst  in  AT  preparation 

c.  To  be  retained  throughout  Qie  program  and  carefully  updated  with 
every  change 

d.  To  be  made  available  to  the  government  during  in-process  review, 
validation,  etc, 

e.  To  aid  the  JPA  developer  in  checkout  and  logic  tree  preparation. 
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These  drawings  will  provide  a  detailed  record  of  the  performance  analysis  for 
troubleshooting  and  an  audit  trail  for  government  reviewers.  For  these  reasons 
the  drawing  annotations  must  be  neat  and  legible  as  exemplified  in  Figure  26. 

5. 8. 3  Checkout  Summary.  The  analyst  shall  develop  a  summaiy  of  all  observ¬ 
able  performance  parameters  on  the  diagrams  in  a  Checkout  Summary  as  shown 
in  Figure  34.  One  or  more  separate  Checkout  Summaries  should  be  developed 
for  each  diagram  annotated  during  performance  analysis.  Enter  the  name  of  the 
component  (e.g. ,  Detection  Subsystem)  and  include  the  reference  designator  from 
the  TIM,  if  the  item  has  one. 

5. 8. 3.1  Checks  Column.  Using  the  information  annotated  on  the  drawings,  pre¬ 
pare  a  list  of  checks  that  must  be  made  to  test  performance  of  each  component 
listed  for  Checkout  on  the  TIM,  including  any  data  to  be  used  in  the  check.  As 
each  check  is  entered  on  the  Checkout  Sinnmary,  mark  the  appropriate  TIM  cell 
to  indicate  that  the  Checkout  entry  has  been  satisfied.  A  completely  checked-off 
TIM  is  assurance  that  the  Checkout  Summaiy  is  complete. 

5. 8. 3. 2  Performance  Parameters  Column.  This  column  must  include  param¬ 
eters  for  each  mode  of  operation  in  which  observations  or  tests  can  be  made  and 
the  range  over  which  they  can  safely  vary.  The  parameters  to  be  listed  should 
include  all  indicators  of  performance  that  are  necessary  to  be  tested.  For 
example,  in  Figure  34,  the  second  check  that  is  listed  for  the  Detection  Subsys¬ 
tem  is  a  check  to  see  that  the  Wide  Scan  Mode  checks  out  acceptably.  To  do  so, 
the  user  must  satisfy  the  following: 

a.  Check  that  the  Control  position  is  okay  (by  checking  that  WIDE  light 
is  on). 

b.  Check  that  the  Antenna  Scan  position  is  okay  (by  checking  that  the 
resolver  output  reading  is  85  {t  1. 5)  degrees). 

c.  Check  that  the  Indicator  presentati<«  is  okay  by  testing  that: 

(1)  The  horizontal  sciii  is  5  (±  .15)  inches 

(2)  The  vertical  scan  is  4  (±  .1)  inches 

(3 )  There  is  a  transmitter  pulse  present 

(4)  There  is  target/clutter  video  present. 

As  suggested  in  the  specification,  the  Checkout  Summaiy  need  not  be  fyped  but, 
if  it  is  not,  it  should  be  neatly  handwritten  and  kept  up  to  date  throuj^out  MTl&A. 


5.8.4  Failure  Mode  and  Fault  Symptom  Analysis 


5.8.4. 1  Source  Data.  The  LSA  data  source  for  the  Failure  Mode  and  Fault 
Symptom  Analysis  is  Data  sheet  Item  Reliability  and  Maintainability  Charac¬ 
teristics.  As  shown  in  Figure  36,  sheet  B  contains  four  types  of  information 
needed  by  the  analyst; 

a.  Item  name  and  part  number 

b.  Component  failure  data  including  failure  modes  and  symptoms,  failure 
effects  and  their  criticality 

c.  The  maintenance  concept  for  the  particular  item 

d.  Estimated  repair  time  for  each  failure  and  the  code  for  the  tasks 
required  for  repair. 

5. 8. 4. 2  The  Analysis  Process.  The  analyst  should  correlate  all  of  the  B  data 
sheets  with  the  TIM.  Check  off  each  TIM  item  for  which  there  is  a  Data  sheet  B. 
Confirm  that  the  cell  listing  for  that  item  has  a  notation  for  Checkout/Trouble¬ 
shooting.  Remember  that  since  Data  sheet  B  reflects  Reliability  Maintainability 
data  of  system  design,  it  is  frequently  in  a  state  of  change  and  the  analyst  should 
be  on  distribution  for  all  Data  sheet  B  changes. 

^Vhen  the  analyst  is  satisfied  that  Data  sheet  B  and  the  TIM  are  in  agreement,  die 
diagrams  annotated  during  performance  analysis  can  be  checked  for  agreement  of 
failure  mode  and  symptoms  with  each  Data  sheet  B.  In  the  Failure  Mode  and 
Fault  symptom  Analysis,  the  analyst  will  determine  the  ways  in  which  each  com¬ 
ponent  can  fail  by  checking  each  against  sheet  B  information.  For  example,  if 
LSA  sheet  B  shows  that  a  processor  control  unit  can  fail  (failure  mode)  when 
there  is  no  communication  between  the  PCU  and  the  computer  (see  Fig^e  36), 
the  performance  analysis  drawings  should  show  (a)  where  and  how  that  communi¬ 
cation  link  can  be  checked  for  failure  (e.g. ,  pin  7,  terminal  board  07),  (b)  what 
operating  parameters  must  be  tested  to  determine  if  it  is  abnormal  (e.g. ,  15.2 
f/sec  pulses,  •fii.5  volts),  (c)  and  what  are  the  failure  symptoms  (e.g. ,  no 
indications  on  the  PCU  control  panel). 

5.8.5  Fault  Symptom  List.  The  analyst  must  develop  from  the  failure  mode  and 
foult  symptom  analysis,  a  list  of  Fault  Symptoms  appropriate  to  the  system  (an 
example  is  shown  in  Figure  37 ) ,  which  will  include  the  symptoms  of  each  failure 
mode  of  each  component  in  the  Checkout  Summary.  This  list  must  also  agree 
with  the  LSA  sheet  B  symptoms.  However,  sheet  B  may  not  include  testing  or 
checking  details,  such  as  meter  readings,  sounds,  or  other  cues  from  the  Check¬ 
out  Summary.  These  details  must  be  added  by  the  analyst  from  the  information 
accumulated  from  the  Checkout  Summary  and  from  the  Performance  analysis 
drawings.  Whenever  possible,  the  analyst  should  create  the  failure  mode  on  the 
system  Inserting  faults,  observing  and  listing  each  symptom. 
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FIGURE  36.  Input  data  sheet  B  used  for  failure  mode  and  fault  symptom  analysis 


Fault  Symptoms 
for 

Teletype  Interface  Card 

No  data  received  at  either  terminal. 

Garbled  data  received  on  only  one  TTY  unit  (at  rear  terminal) 

Garbled  data  received  on  only  one  TTY  (at  far  terminal) 

Garbled  data  received  on  only  one  TTY  (at  far  terminal) 

a.  Units  1,  2,  3,  4,  5  not  functioning 

b.  Units  6,  7,  8,  9,  10  not  functioning 

Garbled  data  simultaneously  received  on  five  related  TTY  units  (at  far 
terminal) 

a.  BEB  alarm  not  active 


The  analyst  must  prepare  a  separate  Fault  ^mptom  List  for  each  operational 
mode  of  the  system  or  equipment,  where  each  mode  creates  different  fault 
symptoms. 

5. 8. 6  Action  Trees.  An  action  tree  (AT)  shall  be  developed  for  each  fault  symp¬ 
tom  identified  on  the  Fault  Symptom  List.  An  action  tree  is  a  branching  tree  out¬ 
line,  or  block  diagram,  of  the  components,  assemblies,  or  equipments  that  can 
cause  the  fault  symptom,  together  with  procedural  information  necessary  for 
later  use  by  the  LTTA  developer  in  explaining  diagnostic  procedures.  The  title 
of  the  AT  is  the  fault  symptom  it  addresses  and  diagnoses. 

5.8.6. 1  Developing  the  Troubleshooting  Logic.  The  analyst  should  construct  the 
action  tree  from  those  components  in  the  TIM  that  can  contribute  to  the  fault 
symptom  involved.  The  AT  must  be  prepared  from  a  basic  knowledge  of  the 
logical  hierarchy  of  components  as  in  Figures  38  and  39,  together  with  a  modi¬ 
fied  half-split  fault  isolation  technique.  The  AT  procedure  must  optimize  the 
following  technician  considerations  to  ensure  that  minimum  fault  isolation  time 
has  been  achieved: 

a.  Time  to  gain  access  to  the  component 

b.  Time  to  test  the  component 

c.  Reliability  of  parts  involved  and  of  replacement  parts 

d.  Requirements  of  tools  and  test  equipment  to  be  used 

e.  Modified  half-split  troubleshooting  logic  (explained  below ) . 

Action  trees  should  contain  a  synopsis  of  all  essential  and  pertinent  information 
that  will  be  needed  by  the  JPA  developer  to  prepare  a  LTTA  from  the  AT  and 
other  MTI&A  products.  This  includes  warnings,  cautions,  notes,  power  turn-on 
procedures,  pre-checkout  procedures,  reference  diagrams,  initial  switch  set¬ 
tings,  etc.  Each  AT  should  be  prepared  assuming  only  one  malfunction  at  a 
time  is  being  addressed  and  the  arrangement  of  components  must  be  in  the  order 
of  their  importance  as  most  probable  causes  of  the  fault.  Selection  of  support 
equipment  must  be  limited  to  those  items  found  in  the  Support  Equipment  Guide. 
The  first  step  in  developing  the  logic  of  the  AT  is  to  develop  a  schematic  repre¬ 
sentation  of  the  functional  relationships  among  components  in  the  system,  a  block 
diagram  that  depicts  the  relationships  among  all  of  the  components  listed  as  pos¬ 
sible  causes  of  the  fault  symptom  for  which  the  AT  will  be  prepared.  Components 
that  cannot  contribute  to  the  fault  should  be  eliminated  from  the  diagram  so  as  to 
keep  the  troubleshooting  logic  as  simple  as  possible.  From  this  hierarchy  of 
components,  the  tree  branches  can  be  developed  by  choosing  test  instrument, 
type  of  test,  and  location  of  test,  and  diagnostic  tests  which  will  determine  the 
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legend: 
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FIGURE  38.  Sample  outline  of  an  action  tree  for  a  complex  fault  symptom 
(without  component  names  and  procedural  information). 
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best  branch  of  the  tree  to  follow,  the  possible  outcome  of  each  test,  and  the  action 
to  be  taken  as  a  result  of  each  test.  In  summary,  develop  the  AT  so  that  it  pro¬ 
vides  a  synopsis  of  the  most  logical,  orderly  troubleshooting  sequence  that  pro¬ 
vides  the  fastest  route  to  fault  diagnosis. 

The  analyst  should  use  Data  sheet  B  information  discussed  earlier  to  aid  in 
establishing  the  AT  logic.  The  Failure  Analysis  portion  of  sheet  B  will  aid  in 
AT  construction  and  also  as  a  check  on  the  completeness  of  the  AT. 

5. 8. 6. 2  Modified  Half-Split  Troubleshooting  Strategy^ .  Selection  of  the  best 
branch  to  perform  a  troubleshooting  test  is  of  primary  importance.  Test  bran¬ 
ches  should  be  selected  in  such  a  way  as  to  divide  all  of  the  suspect  components 
for  the  fault  symptom  on  the  block  diagram  into  two  equal  groups  (as  nearly  as 
possible).  For  the  component  block  diagram  shown  below,  if  all  components 
have  equal  failure  probability  and  are  equally  accessible,  the  first  test  location 
would  be  at  point  A  since  the  choice  permits  dividing  the  components  most  nearly 
in  half.  No  other  test  point  permits  better  than  an  8-3  split.  If  a  "good"  indi¬ 
cation  is  found  at  A,  the  second  test  should  be  at  B  or  C.  If  a  "bad"  indication 
is  found  at  A,  the  second  test  should  be  at  D.  Each  check  eliminates  about  half 
of  the  components  from  consideration.  These  components  are  known  to  be 
"good. "  The  choice  of  test  location  between  the  suspect  components  should  be 
such  that  the  check  be  made  at  the  mid-point  of  the  chain,  and  each  succeeding 
check  be  made  at  the  mid-point  of  the  remaining  portion  of  the  chain.  Thus, 
assuming  each  component  has  an  equal  probability  of  failure,  the  branching  pro¬ 
ceeds  by  halving  the  probabilities  that  the  malfunctioning  component  lies  on  one 
side  or  the  other  of  the  check.  This  strategy  defines  the  half-split  technique  of 
troubleshooting. 


Joyce,  R.P. ,  Chenzoff,  A.  P. ,  Mulligan,  J.F. ,  and  Malloiy,  W.  J.  Fully pro- 
ceduralized  job  performance  aids;  Handbook  for  JPA  developers.  AFHRL-TR- 
73-43(11),  AD-775  705.  Wright  Patterson  AFB,  OH:  Advanced  ^sterns  Division 
Air  Force  Human  Resources  Laboratory,  December  1973. 
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The  pure  half-split  technique  just  described  is  seldom  the  most  economical  for 
100  percent  of  the  checks,  because  of  practical  constraints.  The  half-split 
strategy  should  be  modified  by  introducing  the  following  considerations: 

a.  Reliability.  Checks  for  items  with  high  failure  rates  should  precede 
checks  for  items  with  lower  failure  rates. 

b.  Accessibility.  Checks  that  are  "quick  and  easy  "  should  precede  checks 
that  involve  extensive  or  time-consuming  disassembly.  Remember  that  the  best 
AT  from  a  user's  standpoint  is  one  that  finds  the  trouble  in  the  shortest  time. 

c.  Probability  of  Malfunction  Introduction.  Those  checks  which  involve 
activities  with  high  probability  of  accidental  malfunction  introduction  should  be 
deferred  toward  the  end  of  the  procedure.  Whenever  a  static  check  (power  off) 
and  a  dynamic  check  can  reveal  roughly  the  same  diagnostic  information,  the 
static  check  is  preferred. 

d.  Location  of  the  Technician.  Other  things  being  equal,  the  sequence  of 
checks  should  minimize  the  movement  of  the  technician  from  one  location  to 
another. 


e.  Test  Equipment  Seti^).  An  unusually  time-consuming  test  equipment 
setiq)  should  be  weighed  against  the  infqrmation  it  can  provide  to  consider  whether 
its  use  should  be  presented  earlier  or  later  in  the  check  sequence. 

The  analyst  must  include  procedural  step  data  in  the  AT  where  changes  in  equip¬ 
ment  condition  are  required  to  permit  a  check,  when  method  of  access  must  be 
specified,  or  when  test  equipment  settings  must  be  specified. 

Include  a  corrective  action  step  at  the  end  of  each  branch  of  the  AT,  and  identify 
any  follow-on  or  related  tasks  (e.g. ,  return  to  checkout)  that  the  LTTA  devel¬ 
oper  should  know. 

5. 8. 6. 3  Action  Tree  Data.  Action  trees  shall  contain  the  following  information: 

a.  Brief  procedural  steps  that  will  provide  the  LTTA  developer  with 
technical  guidelines  on  developing  the  checkout  and  logic  tree  trouble¬ 
shooting  for  operations  where  no  decision  is  required,  such  as  in 
Figure  39.  In  the  statement  "Check  condition  of  fuse  A8F1,"  the 
analyst  provides  data  for  the  LTTA  developer  to  use  as  source  data 

in  preparing  detailed  Logic  Tree  test/decision  boxes. 

b.  Repair  or  replacement  steps,  which  direct  the  repair  or  replacement 

of  a  faulty  component.  The  component  to  be  repaired  or  replaced  should 
be  identified  the  same  nomenclature  or  reference  designator,  as 
listed  in  the  TIM. 
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c.  Decision  branches  in  the  tree  should  identil^  the  diagnostic  tests  to  be 
made,  the  possible  outcomes,  and  the  action  to  be  taken  as  a  result  of 
each  outcome.  Make  certain  that  the  following  data  are  included: 

(1)  Name  and  model  number  of  test  instrum^t  (if  any) 

(2)  Type  of  reading  (e.g. ,  pressure,  voltage) 

(3)  Location  of  test  points 

(4)  Range  of  acceptable  values  for  the  reading 

(5 )  Action  to  take  as  a  result  of  each  possible  outcome  of  the  check. 

5. 8. 6. 4  Action  Tree  Development  Rules.  The  analyst  shall  develop  each  AT 
according  to  the  following  rules  and  strategies:  (Refer  to  Figure  39  for  applica¬ 
tion  of  these  rules. ) 

a.  Only  one  fault  s}rmptom  is  observable  at  a  time  and  only  one  fault  exists 
in  the  system  at  a  time. 

b.  Each  point  of  test  shall  be  selected  to  obtain  the  greatest  amount  of 
fault  isolation  information  for  the  action  taken  (i.e. ,  the  modified  half¬ 
split  strategy).  Instructions  for  performing  the  test  shall  be  concise, 
simply  worded,  and  arranged  in  specific  steps  (see  A).  The  analyst 
shall  make  reference  from  the  test  steps  to  an  attached  drawing  or 
other  reference,  for  physical  identification  and  location  of  components 
involved. 

c.  When  a  test  result  shows  that  the  fault  does  not  lie  in  a  specified  section 
of  the  system ,  the  branch  of  the  tree  representing  that  section  should 
not  be  accessible  for  later  troiible  isolation  tests  (i.  e. ,  no  further  test¬ 
ing  is  permitted  in  that  section  of  the  system)  (see  B). 

d.  The  first  tests  to  be  done  will  normally  be  those  that  use  meters, 
switches,  annunciators,  warning  lights,  and  other  built-in  test  equip¬ 
ment.  The  human  senses  for  sight,  sound,  and  touch  should  also  be 
used  to  advantage  in  the  testing  process. 

e.  Tests  that  must  be  done  with  external  test  equipment  will  normally 
appear  later  in  the  testing  process. 

f.  Two  or  more  tests  shall  not  cause  a  closed  loop  in  the  strategy  (i.  e. , 

a  situation  wherein  one  fault  is  isolated  from  two  branches  of  the  action 
tree. 


g.  No  test  shall  result  in  a  dead  end  <i.e. ,  a  situation  in  which  the  LTTA 
developer  is  left  to  devise  a  strategy  for  continuing  the  trouble  isolation 
procedure). 

h.  Every  test  must  yield  a  reliable  result  compatible  with  a  yes  or  no 
question.  There  shall  be  no  possibility  of  a  third  ambiguous  result. 

i.  A  serial  (nonbranching)  sequence  in  which  one  item  after  another  is 
checked  for  a  pass/ fail  condition  until  the  fault  is  found  (as  in  doing  a 
Checkout )  is  permissible  onfy  where  it  is  the  only  possible  sequence 
for  testing. 

j.  The  tests  in  each  branch  shall  result  in  accomplishing  (»e  of  the  follow¬ 
ing,  as  applicable  to  the  respective  maintenance  level  and  authorized 
maintenance  procedures: 

(1 )  Determine  which  one  of  two  components  is  faulty. 

(2)  Determine  that  a  component  is  faulty  or  that  an  additional  test 
must  be  made. 

(3)  Determine  that  further  checkout  or  test  must  be  made. 

k.  Each  AT  test  instruction  shall  provide  the  LTTA  developer  with  enough 
information  to  develop  complete  logic  tree  instructions  (see  C). 

l.  Corrective  action  instructions  at  the  ends  of  the  branches  shall  include 
both  the  corrective  action  to  be  taken  and  follow-on  to  be  done  (see  D). 

m.  Corrective  action  instructions  shall  include  one  of  the  following,  as 
required  actions: 

(1)  Repair,  replacement,  adjustment,  or  alignment  of  a  specific  unit, 
part,  or  piece  (see  E). 

(2 )  Further  testing  of  the  assembly  or  subassembly  to  further  isolate 
the  fault  (see  F). 

5.8.6. 5  Action  Tree  Format.  The  specification  permits  any  format  that  permits 
a  well  organized  AT  structure  and  is  logical,  legible,  and  complete.  The  sample 
AT  in  Figure  39  would  be  acceptable  in  handwritten  or  typed  format. 


6.  DEVELOPING  MTIAA  WITHOUT  THE  AID  OF  AN  LSA  DATA  BASE 


The  contractor  is  required  to  perform  a  thorou^  MTI&A  whether  or  not  LSA  data 
are  available.  This  section  provides  guidance  for  contractor  analysts  to  perform 
effective  task  analysis  when  no  LSA  data  base  exists. 

6.1  Performing  Ts*  IdsntHiestion.  Task  identification  is  the  process  by  which  the 
contractor  defines  all  hardware  items  and  related  tasks  necessary  in  order  to 
carry  out  the  system  maintenance  concept  and  provide  a  complete  procedural 
data  base  for  JPA  developers  and  for  technicians  at  either  Organizational  or 
Intermediate  level,  or  both.  The  results  of  the  task  identification  process  are 
recorded  on  the  Task  Identification  Matrix  (TIM)  form.  The  analyst  should  use 
the  most  formal  equipment  breakdowns  available  as  the  basis  for  TIM  preparation. 

6.1.1  ^aAerln2_Source_^tafor&eTIB^  The  analyst  should  consult  a  variety 
of  source  data  to  aid  development  of  the  TIM  and  ensure  that  the  most  thorough, 
accurate,  and  current  parts  Information  is  being  used  as  the  cornerstone  of  the 
MTI&A  process,  the  TIM.  As  a  minimum,  the  document  selected  from  the  types 
listed  in  Section  4. 5  must  contain  the  formal  name  and  part  number  for  each  item 
repairable  or  replaceable  at  O  or  I  level.  The  analyst  may  have  more  than  one 
document  from  which  to  select  the  best  equipment  breakdown  for  Ihe  TIM,  and  the 
available  data  may  be  different  for  new  or  developing  systems  than  for  fielded  or 
operational  systems. 

Because  of  varying  contractual  considerations,  schedules,  eystem  environments, 
and  the  like,  there  is  no  ironclad  rule  for  the  "best"  document  to  use.  The  list 
below,  therefore,  is  only  a  suggested  sequence  by  which  the  analyst  should  con¬ 
sider  each  available  document.  The  analyst  must  Judge,  with  the  aid  of  subject 
matter  experts,  which  is  the  most  complete  and  current  document.  Note  that  the 
task  identification  and  analysis  process  is  greatly  simplified  if  the  equipment 
breakdown  can  be  purged  of  all  Etepot  level  maintenance  parts. 


6. 1.1.1  New  systems 


a.  Provisioning  Parts  List 

b.  Existing  Illustrated  Parts  Breakdowns  (IPBs),  Repair  Parts  and  Special 
Tools  Lists  (RPSTLs),  T.O.s,  and  T.M.s 

c.  Parts  lists  in  commercial  literature 

d.  Bills  of  material  on  engineering  documentation. 
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6.1. 1.2  Operational  Systems 


a.  Provisioning  Parts  List 

b.  Existing  IPBs  or  RPSTLs 

c.  Work  Unit  Code  Manuals 

d.  T.C.T.O.s 

e.  Parts  Utilization  Summaries 

f.  AFTO  Form  22 's  (for  parts  changes). 

6. 1.2  Filling  Out  the  TIM  Form.  The  analyst  must  prepare  a  TIM  form  that 
will,  when  correctly  filled  out,  provide  task  identification  data  as  required 
the  specification.  Develop,  copy,  or  modify,  if  necessary,  a  TIM  form  such  as 
shown  in  Figure  40,  with  enough  copies  to  incorporate  all  O  and  I  level  parts  in 
the  system.  If  an  up-to-date,  complete  IPB,  Repair  Parts  and  ^[>ecial  Tools 
List,  Provisioning  List,  or  commercial  manual  parts  breakdown  is  available, 
the  specification  permits  the  analyst  to  develop  the  TIM  by  adding  or  pasting 
down  a  blank,  preprinted  maintenance  function  matrix  to  the  equipment  break¬ 
down  such  as  shown  in  Figure  8. 

The  maintenance  functions  that  should  ordinarily  be  covered  in  the  matrix  col¬ 
umns,  to  the  extent  th^  are  ai^ropriate,  are:  adjust,  align,  calibrate,  checkout/ 
troubleshoot,  clean,  disassemble/assemble,  replace,  lubricate,  remove/install, 
repair,  service.  Maintenance  functions  can  also  be  coded  as  shown  in  Figure  4. 

If  the  system  requires  particular  maintenance  functions,  such  as  inspect,  or 
diagnostic,  to  indicate  that  the  component  is  checked  or  diagnosed  by  a  diagnostic 
program  as  in  Figure  4,  the  analyst  should  add  it  to  the  columns. 

The  column  headings  across  the  top  of  the  matrix  are:  (a)  Codes  column  for 
equipment  breakdown  (e.g. ,  FGC  Codes);  (b)  Description  column  in  which  the 
item  (subsystem,  assembly,  subassembly,  or  part)  is  identified;  (c)  the  Part 
Number  column,  where  the  item  part  number  is  recorded;  and  (d)  the  various 
"fimctions  "  columns  for  each  of  the  maintenance  functions.  R  desired,  diese 
columns  may  be  in  another  sequence  on  the  TIM,  than  listed  here.  The  analyst 
may  find  it  beneficial  to  add  a  "Reference  Designator  "  column  for  heavily  elec¬ 
tronic  systems.  For  many  systems,  reference  designators  are  set  forth  in 
schematic  diagrams  to  identify  each  eqxtipment  item  in  terms  of  its  location  and 
function  within  the  system. 

The  intersection  of  each  item  or  part  listing  in  the  part  column  of  the  TIM  form 
with  a  "Maintenance  Function"  column  is  called  a  "cell."  Each  cell  defines  a 
theoretically  possible  task.  The  entries  to  be  made  in  each  cell  indicate  the 
actual  tasks,  if  any,  to  be  performed  on  each  hardware  item,  and  the  mainte- 
vel  at  which  each  is  to  be  performed. 


NTIFICATION  MATRIX  -  AIRCRAFT  CANNON  XG-88 
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6. 1.2. 1  Code  and  Description  Columns.  The  Code  columns  of  the  TIM  are 
intended  to  show  the  relationship  and  subordination  of  each  system,  assembly, 
subassembly  and  part  that  is  maintainable  at  the  O  or  I  levels.  On  some  con¬ 
tracts,  an  adequate  system  coding,  such  as  FGC  codes  will  be  readily  available 
to  the  analyst,  as  part  of  a  provisioning  document.  However,  if  no  such  system 
is  available  to  satisfy  the  specification  requirements,  the  analyst  must  develop 
a  code  for  each  equipment  item.  The  level  of  coding  to  be  assigned  will  be 
determined  by  the  complexity  of  the  equipment.  On  small,  less  complex  equip¬ 
ments,  the  use  of  a  four-level  numerical  coding  may  be  sufficient,  whereas  on 
larger  or  more  complex  equipments,  the  use  of  additional  levels  of  coding  will 
be  required.  The  assigned  coding  may  be  purely  numerical  such  as: 


CODE 
1  2 
1  2  1 
1  2  2 
12  2  1 
12  2  2 


DESCRIPTION 

DMM  gun  mount  assembly  XM161 
Mounting  kit,  boresi^t 
Chute  assembly,  return 
Corner,  chute,  upper 
Chute,  feed 


or  made  up  of  a  combination  of  alphabetical  symbols  and  numerical  numbers 
such  as; 


CODE  DESCRIPTION 


AL 

001 

ENGINE  INSTRUMENTATION 

AM 

002 

ALCC  SYSTEM  INSTALLATION 

AN 

003 

ALCC  STAFF  CONSOLE  POSITIONS  1  AND  2 

AP 

004 

TELETYPE  SYSTEM  -  HIGH  SPEED 

AQ 

005 

SECURE  DIGITAL  COMMUNICATIONS  INSTALLATION 

Most  important  is  that  selected  coding  method  is  simple  and  provides  a  system 
by  which  the  analyst  can  easily  recognize  the  relationship  of  every  item  to  its 
next  higher  assembly.  Before  any  coding  is  assigned,  the  analyst  must  deter¬ 
mine  how  the  system  is  organized,  with  the  aid  of  system  functional  drawings 
such  as  block  diagrams,  schematics,  mechanical  layout  drawings,  or  from 
explanation  the  SME.  Once  organized  into  a  hierarchy  of  distinct  subsystems, 
main  groups,  assemblies,  subassemblies,  etc. ,  as  the  system  organization  dic¬ 
tates,  codes  can  be  assigned  to  each  individual  item.  Since  each  coding  position 
identifies  a  specific  level  of  assembly,  each  system  or  equipment  shall  be  broken 
down  into  the  following  categories. 
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a.  First  Level  Assembly.  First  level  assemblies  are  usually  the  major 
systems.  They  may  be  mechanical  systems  such  as  the  hydraulic  system,  land¬ 
ing  gear  system ,  or  fuel  system  or  electronic  systems  such  as  the  transmitting 
system,  receiving  system,  or  central  data  computer.  This  level  is  identified 

the  first  one  or  two  characters  of  the  group  coding. 

b.  Second  Level  Assembly.  Second  level  assemblies  are  the  subsystems 
within  the  major  systems.  They  are  identified  the  second  or  third  character 
of  the  group  coding.  For  example,  a  major  system  such  as  a  landing  gear  sys¬ 
tem  may  be  comprised  of  a  wheel  assembly,  hub  assembly,  and  landing  strut 
assembly.  In  this  case,  the  wheel  assembly,  hub  assembly,  and  landing  strut 
assembly  are  each  a  subsystem  of  the  overall  landing  gear  system.  Each  per¬ 
forms  a  specific  sub- function  within  the  overall  function  of  the  major  system. 

c.  Third  Level  Assembly.  Third  level  assemblies  are  usually  individual 
components  within  the  end  item.  They  are  identified  by  the  third  or  fourth  char¬ 
acter  of  the  group  coding.  Components  are  the  individual  items  such  as  wheels, 
hubs,  or  hydraulic  cylinders. 

d.  Additional  Coding  Levels.  On  more  complex  equipment  breakdowns 
additional  (fifth  and  sixth)  coding  positions  may  be  required  to  identify  repair¬ 
able  subassemblies  and  detail  parts  within  a  component.  On  some  contracts, 
the  analyst  may  find  complete  reference  designators  or  Work  Unit  Codes 
assigned  to  equipment  breakdowns  by  Government  or  contractor  personnel. 

These  designations  or  codes  will  suffice  for  TIM  coding  because  most  mainte¬ 
nance  significant  components  and  detail  parts  are  identified. 

6. 1.2.2  TIM  Cells.  The  analyst  must  decide  for  each  TIM  cell  whether  or  not 
a  maintenance  task  will  be  required  for  that  equipment  item.  If  so,  the  analyst 
must  then  decide  whether  the  maintenance  task  is  to  be  done  at  O  or  at  I  level. 
Finally,  the  analyst  decides  where  the  task  should  be  documented,  in  a  JGM,  or 
in  a  LTTA  manual.  In  order  to  make  these  various  decisions,  the  analyst  must 
ask  a  number  of  questions  as  described  below.  The  preferred  way  to  fill  in  the 
TIM  is  to  do  it  with  an  SME  who  can  provide  accurate  answers  to  the  analyst's 
questions  with  pertinent  data  (e.g. ,  drawing  numbers  and  data  sources)  which 
can  be  entered  in  the  Notes  column.  This  method  has  the  advantage  that  the  ana- 
fyst  can  control  the  task  identification  process  and  use  the  SME's  time  most 
effectively. 

Another  way,  if  the  analyst  is  familiar  widi  the  equipment  and  the  maintenance 
cmicepts,  is  to  fill  in  the  cells  from  available  data  and  then  have  the  SME  review 
the  TIM,  correcting  and  annotating  it  as  portions  of  it  are  completed. 


In  any  case,  the  analyst-SME  team  must  "identify"  and  "analyze"  by  asking 
the  following  questions: 

—  Can  a  maintenance  function  be  performed  on  this  item  by  the  fypes 
of  technician  user  identified  in  the  Government  preliminary  user 
profile? 

—  At  what  level  of  maintenance,  O  or  I  or  both,  will  the  task  be 
performed? 

—  Is  the  technician  described  for  O  or  I  maintenance  capable  of 
performing  it? 

—  Are  there  spares  allocated  for  that  item  if  a  replacement,  disassemble, 
or  repair  task  has  been  identified? 

The  only  major  decisions  left  for  the  analyst  on  task  identification  would  be  to 
determine  where  the  task  should  be  documented  1^  answering  these  questions: 

—  Is  the  task  too  simple  to  be  included  in  a  manual?  (Leave  a  blank 
in  right  portion  of  cell.) 

—  Is  the  task  a  fixed  procedure;  one  that  involves  no  checkout  or 
troubleshooting  by  the  user?  (Enter  a  J  for  JGM  in  the  cell.) 

—  Is  the  task  one  that  requires  checking  and  trouble  diagnosis?  (Enter 
an  L  for  LTTA  in  the  cell.) 

In  developing  the  TIM  the  analyst  will  find  it  very  helpful  for  later  analyses  to 
obtain  answers  to  the  following  questions  and  note  them  in  the  Notes  column. 

—  How  much  time  does  the  task  take? 

—  What  support  and  test  equipment  is  required  for  the  task? 

—  Is  there  any  special  skill  needed  by  maintenance  personnel  to  perform 
this  task?  (This  may  necessitate  modifying  the  preliminary  user  pro¬ 
file,  and  including  more  detail  in  the  task  description  worksheets  and 
level  of  detail  guide.) 

The  codes  to  be  entered  in  each  cell  must  be  drawn  from  the  list  shown  in 
Figure  11. 

6. 1.2.3  Ensuring  TIM  Completeness.  Omission  of  any  hardware  item  from  the 
TIM  can  result  in  omission  of  one  or  more  tasks  from  the  data  base,  and  hence 
from  the  JPAs.  It  is  therefore  critical  diat  the  analyst  prepare  and  check  the 
list  of  hardware  items  with  great  care  and  that  the  list  is  thoroughly  reviewed 
for  completeness  1^  an  SME. 


6. 1.2.4  Completing  Task  Identification.  If  there  are  equipment  items,  however, 

for  which  all  available  data  have  not  supplied  the  decision  on  task  identification 
and  if  there  are  cells  with  the  analyst  must  make  task  decisions  from 

other  data.  These  decisions  can  be  based  on  existing  equipment  descriptions  or 
task  descriptive  data,  or  from  experience  with  similar  equipment  items  1^  the 
SME  or  by  the  analyst. 

6. 1.2.5  Notes  Column.  The  analyst  should  consider  the  Notes  column  as  a 
convenient  way  to  record  significant  facts,  or  to  record  data  generated  or  gath¬ 
ered  during  TIM  development  for  later  use.  Information  such  as  the  following 
can  be  of  significant  value  during  later  analyses  efforts. 

a.  Drawing  revision  levels 

b.  Deficiencies  in  the  data 

c.  Interrelationships  among  tasks 

d.  Reasons  for  further  resolution  (?  )  entries 

e.  fecial  information  such  as  techniques  or  problems  unearthed 
during  research 

f.  Time  to  perform  the  task 

g.  Number  of  people  to  perform  the  task 

h.  Special  skill  required  to  perform  the  task 

i.  Siqjport  or  test  equipment  required  to  perform  the  task. 

6. 1.2.6  Expanded  TIM.  The  specification  AFHRL-TR- 79-50  defines  expansion 
of  the  Basic  TIM  to  accommodate  special  information  about  the  identified  tasks 
where  the  Acquisition  agency  has  designated  a  requirement.  When  expansion  is 
required,  the  analyst  should  develop  the  TIM  form  to  allow  for  additional  col¬ 
umns  of  data  or  a  separate  form  to  be  attached  to  the  TIM  if  the  data  does  not 
lend  itself  to  additional  columns.  The  TIM  can  be  expanded,  for  example,  to 
include  data  such  as 

1.  Depot  level  breakdown  of  items 

2.  Task  performance  times 

3.  Tasks  to  be  considered  for  special  skills  training 

4.  Task  Frequency  (e.g. ,  on  preventive  maintenance  tasks) 

5.  l^eclal  training  requirements. 
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6.2  Performing  a  User  Analysii.  In  order  to  analyze  and  define  the  user  and  develop 
a  complete  MTI&A  User  Profile,  the  analyst  will  depend  primarily  on  the 
government-supplied  Preliminary  User  Profile.  If  this  profile  indicates  that 
maintenance  personnel  with  similar  training  and  skills  are  maintaining  other 
systems  or  equipment  in  the  field,  the  analyst  should  consider  observing  the 
user  in  action.  By  watching  a  technician  perform  tasks  on  similar  equipment, 
the  analyst  may  gain  important  insight  into  the  practical  skills  required.  For 
example,  if  called  upon  to  develop  MTI&A  on  aircraft  systems  for  the  first  time, 
an  analyst  may  learn  more  about  the  skills  required  of  an  O  or  I  aircraft  techni¬ 
cian  by  the  interviewing  and  observing  typical  users  at  their  daily  tasks  than 
through  any  other  method.  During  User  Analysis,  the  analyst  must  seek  and 
find  answers  to  these  questions: 

1.  What  is  the  expected  technical  training  and  experience  of  the  average 
technician  who  will  perform  Organizational  maintenance  tasks?  Inter¬ 
mediate  maintenance  tasks? 

2.  Will  this  training  and  experience  suffice  for  maintaining  this  system, 
or  will  additional  training  be  required? 

3.  What  additional  training  will  be  required?  Must  additional  skills  be 
developed?  For  example,  must  the  user  be  trained  in  the  use  of  com¬ 
plex  test  equipment? 

4.  Is  the  skill  specialty  described  in  the  Preliminary  User  Profile  ade¬ 
quate,  or  does  the  contractor  recommend  that  some  other  skill  specialty 
be  utilized? 

5.  Are  there  special  work  conditions  important  to  system  repair  that 
must  be  considered  when  defining  the  user? 

6.  If  the  government-selected  skill  specialty  is  inadequate,  must  the 
analyst  accommodate  this  deficiency  by  providing  additional  proce¬ 
dures  in  the  task  worksheets?  For  example,  if  the  target  engine 
mechanic  needs,  but  is  not  trained  in  the  use  of,  an  engine  test  set  — 
must  the  task  analysis  worksheets,  and  therefore  the  JPA,  contain 
instructions  on  the  operation  of  the  test  set  and  how  to  interpret  its 
outputs?  If  so,  it  is  important  that  this  skill  deficiency  be  defined  in 
the  User  Profile. 

7.  What  is  the  lowest  level  of  security  clearance  the  user  must  possess 
to  perform  required  tasks? 

6.2. 1  Using  the  Preliminary  User  Profile.  In  the  early  stages  of  a  contract  the 
analyst  must  depend  on  the  Preliminary  User  Profile  supplied  by  the  Acquisition 
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agency.  It  will  define  the  general  background  and  training  of  apprentice  and 
experienced  technicians  who  will  be  responsible  for  maintenance  of  the  system. 

It  will  provide  the  analyst  with  data  on  which  to  base  MTI&A  planning,  such  as 
the  user  technician's  reading  level,  training  school  courses  and  other  educational 
background,  a  skills  inventory,  expected  normal  work  conditions,  and  the  level 
of  supervision.  Later,  in  coordination  with  subject  matter  experts,  the  analyst 
develops  a  Definitized  User  Profile  which  may  modify  the  Preliminary  version 
to  provide  a  more  comprehensive  description  of  the  user. 

6.2.2  Developing  the  Definitized  User  Profile.  The  Definitized  User  Profile  is 
developed  from  data  accumulated  and  studied  by  the  analyst  during  User  Analy¬ 
sis.  It  therefore  will  be  developed  from  studies  and  recommendations  made  by 
the  contractor  task  analysts  and  SMEs.  The  contractor  may  recommend  modi¬ 
fications  or  refinements  based  on  SME  knowledge  of  peculiarities  of  system 
maintenance,  such  as  when  the  complexify  of  system  maintenance  requires  spe¬ 
cial  test  equipment,  unusual  skills,  or  new  skill  specialities.  The  MTI&A 
analyst  shall  develop  this  detailed  profile  for  review  and  assurance  by  all  con¬ 
tractor  SMEs  and  the  Acquisition  agency  personnel  that  the  definition  of  the 
actual  maintenance  technician  user(s)  is  accurate  and  complete. 

If  the  analyst  determines  that  the  Definitized  User  Profile  establishes  a  user 
that  is  different  from  that  described  by  the  Acquisition  agency,  the  contractor 
should  convene  a  conference  to  explain  and  receive  concurrence  in  the  intended 
changes.  This  conference  will  clarify  the  definition  of  the  individuals  who  will 
be  using  the  task  details  in  the  JPA,  including  improved  training  requirements. 
The  product  of  this  conference  is  an  approved,  final,  Definitized  User  Profile, 
which  will  g^ide  the  further  task  analysis  process  and  the  JPA  developers.  The 
contractor  may  find  it  extremely  helpful  to  observe  government-defined  users 
in  their  training  setting  or  in  actual  performance  of  their  maintenance  duties, 
so  as  to  verify  that  their  skills  and  knowledge  equate  with  the  profiled  user. 

6.3  Performing  the  Support  Equipment  Analysis.  The  contractor  must  perform  a 
detailed  analysis  of  all  common  and  special-purpose  test  equipment,  special 
tools ,  and  ground  support  equipment  that  is  necessary  to  maintain  the  system 
or  equipment  at  O  or  I  level.  This  research  will  include  understanding  the 
functions  and  operation  of  all  siq^port  equipment  and  consolidating  this  data  for 
later  use  by  the  analyst  and  the  JPA  developer.  The  analyst  must  be  quite  cer¬ 
tain  in  this  analysis  that  the  support  equipment  list  is  complete  and  accurate 
because  the  list  will  determine  level  of  task  detail  and  affect  the  number  and 
level  of  tasks  to  be  developed  for  the  user.  Note  that,  as  used  in  the  specifica¬ 
tion,  support  equipment  includes  special  tools,  metrology  and  calibration  equip¬ 
ment,  performance  monitoring  and  fault  isolation  equipment,  maintenance  stands, 
and  handling  devices  required  for  maintenance  of  the  system.  During  this  phase 
of  MTI&A,  the  analyst  must  work  closely  with  SMEs  and  system  engineers  to 
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ensure  that  plans  for  support  and  test  equipment  are  closely  coordinated.  A 
change  in  test  equipment  can  have  a  serious  effect  throughout  the  entire  MTl&A 
process.  If  an  engineer  changes  the  type  of  diagnostic  testing,  say  from  auto¬ 
matic  to  manual,  or  changes  the  type  of  test  equipment,  all  analyses  and  products 
may  undergo  a  signficant  revision.  Significant  changes  in  maintenance  support 
equipment  or  concepts  has  greater  impact  on  task  analysis  than  anything  else, 
except  for  sweeping  design  changes.  The  analyst  should  remember  to  keep 
open  communication  lines  with  engineering  personnel  who  are  developing 
AGERDs,  GSERDs,  or  other  forms  of  test  equipment  and  tool  recommendations 
for  Acquisition  agency  approval. 

During  Support  Equipment  Analysis,  the  analyst  should  answer  the  following 
questions: 

1.  What  testing,  measuring,  diagnostic  tools,  and  test  equipment  are 
required  at  Organizational  level?  At  Intermediate  level?  Identify 
each  by  name,  model  number,  part  number,  and  physical  size. 

2.  What  functions  will  the  item  perform  (e.g. ,  the  type,  accuracy,  and 
range  of  readouts)? 

3.  What  additional  skills  or  training  must  be  provided  before  the  profiled 
technician  can  use  it  properly?  For  example,  must  a  special  con¬ 
tractor  training  school  be  completed  before  the  operating  skills  of 
the  technician  will  be  adequate? 

4.  What  are  the  standard  statements  (see  Figure  17)  to  be  used  to  describe 
procedural  steps  using  each  equipment  or  tool? 

6. 3. 1  Gathering  Source  Data  for  the  Siq?port  Equipment  Analysis.  In  order  to 
answer  the  above  questions  on  support  equipment,  the  analyst  should  consult  as 
many  of  the  following  data  sources  as  available: 


Preliminary  or  Definitized  User  Profile  (to  determine  if  user  can 
use  this  equipment) 


Technical  manuals  (operation  and  maintenance)  on  the  support  or  test 
equipment  (to  learn  its  operation  and  functions) 


I 


AGERDs  or  GSERDs  explaining  contractor-justification  of  need  for 
the  item  (to  learn  how  the  equipment  will  be  used  in  testing  and 
troubleshooting ) 


—  Procurement  specifications  explaining  what  the  contractor  expects 

the  equipment  to  test,  its  size,  etc. ,  (to  understand  what  the  con-  | 

tractor's  vendors  are  required  to  supply  or  design)  | 

—  Photographs  or  drawings  of  the  item,  if  technical  manuals  are  not  i 

available  (to  determine  its  physical  size,  controls,  etc.).  j 

Most  support  and  test  equipment  is  off-the-shelf  and  information  is  readily  avail¬ 
able  to  answer  the  analyst's  questions.  However,  when  peculiar  or  special  test 
equipment  is  being  recommended  and  designed,  the  analyst  must  depend  on  pre¬ 
liminary  design  data  or  similar  equipment  in  the  early  development  stages.  The 
analyst  must  follow  its  development  (sometimes  by  a  vendor)  as  closely  as  the 
end  item  equipment,  for  it  has  so  much  impact  on  MTl&A, 

6.3.2  Developing  the  Support  Equipment  Guide.  The  analyst  should  follow  these 
steps  to  produce  an  acceptable  Support  Equipment  Guide: 


a.  Assemble  and  study  all  available  source  data  on  support  equipment, 
including  interviews  with  SMEs  involved  in  support  equipment  development, 
planning  or  procurement. 

b.  On  each  page  of  the  guide,  record  the  title  of  the  system  or  equipment, 
the  date  the  guide  was  developed,  and  the  task  analyst's  name  (see  Figure  17). 

c.  For  each  item,  start  a  new  page,  indicating  the  name  and  number  of 
each  item  of  test  equipment  or  special  tool  used.  Identify  the  item  by  AN  desig¬ 
nation,  if  assigned,  or  by  the  manufacturer's  designation.  Common  types  such 
as  voltmeters  and  signal  generators  must  be  listed.  A  special  tool  is  any  tool 
not  normally  found  in  a  mechanic's  tool  kit. 

d.  For  each  item,  list  all  of  the  functions  for  which  it  is  used.  Consult 
commercial  manuals  that  describe  each  special  tool  and  test  equipment  for  its 
uses. 

e.  In  the  personnel  assumptions  column,  explain  clearly  the  assumptions 
to  be  made  regarding  the  behavioral  skills  and  knowledge  the  user  must  possess 
to  perform  the  function.  Also  explain  the  information  and  directions  that  will 
have  to  be  provided  in  the  JPA  procedures  using  the  item. 

f.  In  the  standard  statements  column,  the  analyst  must  list  all  of  the  exact 
statements  to  be  made  in  the  Task  Steps  portion  of  the  Task  Analysis  Worksheets 
and  the  JPAs  each  time  the  function  is  needed.  The  statement  should  consist  of 
as  many  of  the  actual  words  to  be  used  when  a  certain  category  of  data  is  to  be 
used  in  the  tasks.  The  wording  must  be  consistent  between  similar  or  identical 
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MTI&A  task  data.  Standard  statement  wording  will  depend  on  the  Definitized 
User  Profile,  as  well  as  user  knowledge,  skills,  and  technical  difficulty  in 
operating  the  item. 

6.4  Performing  the  Level  of  Detail  Analysis,  if  the  capabilities  of  the  users  are  over¬ 
estimated,  they  will  not  be  able  to  follow  the  instructions  in  the  JPA.  If  the 
instructions  merely  state  "Check  the  waveform  at  Pin  21001,"  and  the  technician 
does  not  know  where  Pin  21001  is  located,  what  the  waveform  should  be  or  how 
to  check  it,  or  what  the  equipment  state  should  be  before  making  this  check,  then 
this  task  cannot  be  performed.  Too  much  detail,  on  the  other  hand,  slows  down 
task  performance.  It  can  also  increase  errors  in  performance  because  the 
users  may  tend  to  avoid  using  the  JPA  if  it  forces  them  to  wade  through  more 
detail  than  needed.  Arriving  at  the  proper  level  of  detail  for  task  analysis  is 
important.  The  analyst  must  determine  from  the  Definitized  User  Profile  the 
level  of  instructions  that  are  appropriate  to  the  JPA  reader.  The  Level  of  Detail 
Analysis  should  be  performed  in  conjunction  with  or  immediately  following  the 
User  Analysis  because  the  information  concerning  user  skills,  capabilities, 
training  deficiencies,  and  technical  experience  that  it  provides  are  the  same 
criteria  used  to  develop  the  Level  of  Detail  Guide.  For  example,  if  the  Defini¬ 
tized  User  Profile  dictates  that  the  user  has  the  knowledge  and  skills  to  use  an 
oscilloscope,  then  the  Level  of  Detail  Guide  will  reflect  that  capability  by  ex¬ 
cluding  details  of  oscilloscope  operation.  Conversely,  if  the  User  Profile  shows 
that  the  user  will  not  have  knowledge  or  experience  in  the  use  of  a  piston  ring 
groove  wear  gage,  then  the  Level  of  Detail  Guide  will  require  specific  in-text 
detail  each  time  the  gage  is  used  in  a  task. 

6. 4. 1  Developing  the  Level  of  Detail  Guide.  The  Level  of  Detail  Guide  is  a  state¬ 
ment  of  how  detailed  the  information  must  be,  based  on  what  is  known  about  the 
skills  of  maintenance  personnel  and  about  the  equipment  systems.  The  analyst 
shall  develop  the  Guide  in  accordance  with  the  specification  with  additional  ex¬ 
planation  supplied  below.  The  questions  in  the  following  subsection  are  only 
suggestive  of  the  ones  that  should  be  answered  in  the  Level  of  Detail  Guide. 
Additional  questions  will  need  to  be  answered  for  most  systems,  and  some 
suggested  questions  may  not  apply  to  a  given  system.  After  answering  such 
questions,  the  analyst  must  explain  the  directives  in  a  form  similar  to  Figure  6. 

6.4. 1. 1  Discriminations  and  Perceptions.  The  Guide  must  define  the  level  of 
detail  by  answering  questions  such  as: 

a.  Observing  Gross  Indications.  If  a  technician  must  respond  to  a  gross 
indication  such  as  a  light  being  on  or  a  meter  being  out  of  an  acceptable  range  of 
values,  will  the  task  step  merely  name  the  indicator  or  meter  and  state  the  value 
to  be  observed  or  should  there  be  an  illustration  that  shows  the  indicator  in  the 
"on"  state  or  the  meter  in  an  out-of-tolerance  condition? 


b.  Reading  Quantitative  Values.  When  a  technician  must  respond  to  a  pre¬ 
cise  value  on  a  meter  (plus  or  minus  some  tolerance),  will  the  meter  face  always 
be  illustrated?  Which  meters  will  be  treated  differently?  Will  some  meters 
require  special  instructions  on  how  they  are  to  be  read  (e.  g. ,  how  to  make 
interpretations )  ? 

c.  Noting  Relative  Motion.  Will  instruments  be  used  to  detect  relative 
motion  between  components?  How  much  will  have  to  be  said  concerning  the  use 
of  these  instruments?  If  instruments  are  not  used,  how  much  should  be  said 
about  the  technician's  point  of  observation?  Will  the  illustrations  indicate  the 
direction  of  motion? 

d.  Reading  or  Interpreting  Oscilloscope  Patterns  and  Waveforms.  How 
will  standards  for  comparison  be  presented?  What  dimensions  of  the  waveforms 
will  be  specified?  How  much  will  be  said  about  the  appropriate  methods  for 
determining  amplitude,  frequency,  and  shape  of  the  waveforms? 

e.  Noting  Visually  Detectable  Physical  Defects.  Will  standards  for 
comparison  be  presented  or  will  it  be  assumed  that  these  judgments  will  be 
mastered  in  training?  Will  illustrations  show  only  obviously  acceptable  and 
obviously  unacceptable  conditions,  or  will  various  degrees  of  marginally 
acceptable  conditions  be  shown  and  evaluated? 

f.  Detecting  Presence  or  Absence  of  Sounds  and  Vibrations.  Will  the 
sounds  or  vibrations  be  characterized  in  words,  or  will  they  merely  be  named? 
Will  detection  of  vibrations  be  by  feel? 

g.  Discrimination  of  Pitch  or  Other  Characteristics  of  a  Sound.  In  M^at 
term  will  pitch  be  described?  In  what  terms  will  other  characteristics  of  sound 
be  described? 

h.  Discrimination  of  Odors.  How  will  sigpiificant  odors  be  described? 

6.4, 1.2  Problem  Solving  and  Decision  Making.  The  Guide  must  define  the  level 
of  detail  by  answering  questions  such  as*. 

a.  Selection  of  Appropriate  Next  Step  or  Task.  Will  guidance  be  provided 
for  each  decision  that  arises?  In  what  situations  will  the  next  step  or  task  not 
be  specified? 

b.  Performing  Calculations.  What  sorts  of  calculations  will  be  explained 
in  detail?  In  what  cases  will  tables  or  nomographs  be  substituted  for  each  cal¬ 
culation? 
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c.  Exercising  Judgment.  Will  the  technician  be  required  to  make  judg¬ 
ments  without  the  aid  of  JPA?  When? 

d.  Conversion  of  Data  from  One  Form  to  Another.  Will  conversions  (e.g. , 
binary  to  decimal  or  Farenheit  to  Centigrade)  be  aided  by  tables  or  graphs? 

Will  complete  instructions  and  examples  accompany  any  tables  or  graphs  that 
are  presented? 

6.4. 1. 3  Motor  Actions.  The  Guide  must  define  level  of  detail  by  answering 
questions  such  as: 

a.  Activating  Switches.  Will  the  desired  setting  for  the  switch  be  illus¬ 
trated  as  well  as  being  specified  in  the  text?  Will  the  location  of  the  switch  be 
illustrated,  described  in  the  text,  or  neither? 

b.  Adjusting  Continuous  and  Multiposition  Controls.  Will  the  desired 
setting  for  the  switch  be  illustrated  as  well  as  being  specified  in  the  text?  Will 
the  location  of  the  switch  be  illustrated,  described  in  the  text,  or  neither?  Will 
the  direction  of  operation  be  specified  (e.g. ,  clockwise,  to  the  left)? 

c.  Performing  Coordinated  Gross  Bo<fy  Movements.  Will  the  movements 
required  for  moving  and  positioning  hardware  items  be  described  or  merely 
named? 

d.  Performing  Actions  Requiring  Fine  Coordination.  Will  guidance  be 
provided  for  performing  actions  requiring  fine  coordination? 

6.5  Perforining  the  Task  Detail  Analyiis.  The  Level  of  Detail  Analysis  described  in 
Section  6.4  provides  the  rules  for  "how  much  detail"  the  JPA  developer  must 
provide  in  the  task  steps.  The  Task  Detail  Analysis  discussed  here  will  con¬ 
sider  those  rules  in  establishing  for  each  specific  task  "what  must  be  done." 
Note  that  this  analysis  will  not  communicate  "how"  to  do  it  —  that  is  left  to 
the  JPA  developer  to  analyze  from  a  behavioral  approach  and  then  to  communi¬ 
cate  "how  to"  to  the  user.  To  illustrate,  in  Figure  19,  the  analyst  has  deter¬ 
mined  the  task  details  that  must  be  covered  by  the  JPA  developer  in  Removing 
and  Installing  Fuselage  Tank  Units.  In  Sheet  3  of  Figure  19,  the  analyst  des¬ 
cribes  the  task  details  necessary  for  follow-on  maintenance  after  the  tank  units 
have  been  installed.  In  the  second  item  of  that  follow-on  maintenance,  the  task 
detail  analysis  has  determined  that: 

a.  The  access  panels  must  be  installed  after  the  tank  units.  Presume  that 
the  analyst  knows  from  the  Definitized  User  Profile  that  the  technician  will  not 
be  experienced  in  this  installation  and  the  Level  of  Detail  Analysis  indicates  that 
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the  JPA  must  always  give  detailed,  well-illustrated  reassembly  procedures.  The 
Level  of  Detail  Guide,  for  example,  would  have  prescribed: 

Disassembly  and  Reassembly.  For  disassembly  and  reassembly 
(or  removal  and  installation)  the  task  step  will  always  provide  step- 
by-step  reassembly  procedures  and  illustrations  of  attaching  panels, 
hardware,  etc. ,  to  show  all  parts  as  seen  from  the  installer's  position 
relative  to  the  equipment.  Assume  that  the  technician  is  familiar  with 
use  of  the  torque  wrench. 

b.  The  analyst  has  indicated  what  tasks  are  to  be  performed  (i.e. ,  "Secure 
engine  access  panel  screws"  and  later  "Perform  leak  test  of  fuel  tanks.")  The 
JPA  developer  will  illustrate  and  explain  these  tasks  to  the  extent  that  the  task 
analyst  has  directed  in  the  Level  of  Detail  Guide.  Hie  analyst  must  make  cer¬ 
tain  that  every  non-troubleshooting  task  identified  in  the  TIM  for  inclusion  in  a 
JGM  has  been  analyzed  to  determine  the  cues  for  each  task  step,  the  precondi¬ 
tions  for  task  performance,  the  steps  that  are  necessary  for  successful  task 
completion  (including  performance  standards  and  keyed  locator  illustrations), 
identification  of  follow-on  tasks,  and  other  data  that  are  important  for  the  JGM 
developer  to  know.  Most  of  the  task  detail  analysis  is  in  the  actual  writing  of 
task  step  details,  discussed  in  the  following  paragraph. 

6.5.1  Writing  Task  Analysis  Worksheets.  The  contractor  shall  record  the 
results  of  the  analysis  of  each  task  on  Task  Analysis  Worksheets,  one  set  for 
each  task.  The  worksheets  must  contain  all  of  the  information  required  by  the 
specification  and  the  general  format  of  the  worksheets  must  be  similar  to  that 
in  Figure  19.  Legibility,  completeness,  and  accuracy  are  the  primary  require¬ 
ments  for  an  acceptable  task  analysis  worksheet.  The  first  step  in  preparing  a 
worksheet  is  to  fill  in  all  of  the  identifying  and  administrative  data  (circled  item 
numbers  1  to  6  on  Figure  19),  and  Input  Conditions  information  (items  7  to  11) 
as  indicated  on  the  form . 

The  analyst  can  determine  the  Required  Conditions,  item  7,  for  the  task  by 
learning  the  interrelationships  between  tasks  from  SMEs  and  from  early  devel¬ 
opment  of  fypical  or  preliminary  tasks.  Early  in  the  MTI&A  process,  the  analyst 
will  begin  to  find  common  or  typical  tasks  that  will  be  required  as  preliminary  to 
or  part  of  other  tasks.  To  the  extent  possible,  the  analyst  should  try  to  deter¬ 
mine  early  in  the  analysis,  which  are  the  common,  often  used  tasks.  Generating 
the  worksheets  for  common  tasks  earfy  and  knowing  their  content  will  simplify 
the  organization  and  development  of  the  Required  Conditions  entries  for  all  other 
worksheets.  For  example,  if  the  "Removal  of  the  Left  and  Ri^t  Main  Landing 
Gear  Actuator  Valves"  is  a  procedure  that  must  precede  many  other  maintenance 
tasks,  it  is  very  helpful  to  complete  the  worksheet  on  that  task  early  so  that  the 
analyst  knows  where  it  begins  and  ends  when  considering  other  tasks. 
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Data  for  item  8,  which  identifies  the  number  of  persons  required  in  performance 
of  the  task,  is  available  from  the  User  Profile  and  Siq)port  Equipment  Guide. 
When  using  such  input  data,  the  analyst  must  verify  that  the  task,  as  performed 
on  the  real  equipment,  can  be  performed  with  the  personnel  indicated  on  the 
data  sheets.  The  analyst  should  note  the  importance  of  communication  and  co¬ 
ordination  between  members  of  a  team  performing  a  task. 

The  analyst  should  refer  to  the  Support  Equipment  Guide  for  a  listing  of  the  items 
of  support  and  test  equipment,  item  9,  and  supplies,  item  10,  required  for  each 
task.  The  contractor  should  make  certain  that  the  support  equipment  listed  in 
the  task  analysis  worksheet  agrees  with  the  AGERDs  and  GSERDs  data,  includ¬ 
ing  part  numbers,  description,  etc.  Some  or  all  of  the  data  in  the  worksheet 
may  be  invalid  if  the  wrong  model  or  type  of  support  equipment  has  been  used 
in  task  step  details. 

The  analyst  should  ensure  that  all  conditions  which  may  affect  the  safety  of  per¬ 
sonnel  or  equipment  have  been  considered  and  listed  under  item  11  of  the  work¬ 
sheet.  Overall  notes,  cautions,  and  warnings  shall  be  included  under  this  item, 
even  though  they  will  also  be  repeated  just  preceding  the  task  step  to  which  they 
apply.  To  ensure  that  all  such  data  are  included,  the  analyst  should  consult 
SMEs  who  may  be  responsible  under  the  contract  for  hazard  identification  if 
MIL-STD-882,  ifystem  Safety  Program  Requirements,  is  invoked.  Evaluation 
of  component  fault  hazards  and  their  causes  and  hazardous  effects  is  important 
data  that  must  be  investigated  and  included  in  the  worksheets.  If  no  formal 
safety  requirements  are  included  in  the  contract,  the  analyst  should  seek  out 
such  information  from  subject  matter  experts. 

The  heart  of  the  task  analysis  process  is  in  the  writing  of  task  step  details  for 
the  worksheet  items  12,  13  and  14  by  the  MTI&A  analyst.  The  description  of 
each  step  must  communicate  enough  detail  and  guidance  so  that  the  JPA  devel¬ 
oper  will  understand  the  bahaviors,  cues,  and  technical  information  the  user 
needs  to  perform  the  task  successfully. 

Each  task  must  be  analyzed  to  define  in  precise  terms  what  the  user  sees  or 
detects  (behavioral  cues),  and  what  the  responses  must  be  to  accomplish  the 
task  objectives.  To  ensure  a  precise  understanding  of  all  the  task  conditions, 
cues,  responses,  and  objectives,  the  analysts  must  put  themselves  in  the  role 
of  the  technician  trying  to  perform  the  task. 

The  analyst's  aim  is  to  determine  the  optimum  way  to  perform  each  task  step 
and  to  ensiure  that  all  of  the  cues  to  which  the  user  must  respond  have  been 
communicated. 

A  cue  is  simply  a  signal  for  action  by  the  technician.  It  can  be  a  condition  ("If 
the  alarm  light  is  on"),  an  event  or  situation  ("When  the  system  is  ready"),  or 
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the  completion  of  the  preceding  task  step.  The  analyst,  then,  must  organize  the 
cues  in  optimum  sequence  that  will  start  the  task,  proceed  through  the  necessary 
performance  steps,  and  then  end  the  task.  In  analyzing  the  technical  detail  in 
conjunction  with  behavioral  cues  and  responses  the  analyst  should  ask; 

a.  What  conditions  exist  that  make  it  possible  for  the  procedure  to  start 
(initiating  cues)  ?  For  example: 

(1 )  Is  removal  of  the  aircraft  fuel  tanks  a  task  that  can  be  performed 
at  Intermediate  maintenance  level  safely? 

(2)  Is  the  aircraft  safe  for  maintenance? 

(3)  Has  the  aircraft  been  defueled? 

(4)  Has  it  been  drained  and  purged? 

(5)  Have  preparatory  tasks  (from  other  procedures)  been  performed 
(e.g. ,  removal  of  access  panels)? 

b.  What  are  the  various  technician  responses  that  trigger  the  next  cue  ? 
Usually  the  completion  of  the  preceding  step  triggers  the  next,  in  a  chain  of  task 
steps.  In  the  body  of  task  steps,  the  analyst  must  consider  the  behavioral  dis¬ 
criminations  and  perceptions,  problem  solving  and  decisions,  and  motor  actions, 
described  in  paragraphs  6. 4.1.1,  6.4. 1.2  and  6. 4. 1. 3.  Each  of  those  questions 
must  be  analyzed  to  ensure  the  task  steps  are  complete.  In  addition  to  these 
discriminations  and  perceptions,  the  analyst  must  determine  throu^  inquisitive 
research  whether  there  is  a  better  technique  or  a  special  trick  that  will  help  the 
user.  For  example,  "Would  loosening  the  access  plate  for  the  clutch  assembly 
give  the  technician  better  access  to  the  gear  train?"  or  "Would  the  use  of  a 
printed  circuit  board  extractor  eliminate  steps  d  and  e?" 

c.  What  cues  signal  the  end  of  the  task?  A  common  problem  in  MTI&A  is 
to  miss  or  omit  final  wrapiq}  steps  because  they  are  so  obvious  (e.  g. ,  "Discon¬ 
nect  test  equipment,"  or  "Tighten  panel  screws") .  Because  these  ending  steps 
are  often  critical,  the  analyst  must  ensure  that  accurate  cues  are  provided  to 
the  JPA  developer. 

It  is  important  to  reiterate  the  need  for  validation  of  task  steps  through  perform¬ 
ance  by  the  analyst  or  l?y  observation  of  performance  by  a  typical  user.  The 
analyst  should  ensure  the  validity  and  completeness  of  worksheet  information  by 
actual  testing  with  such  typical  questions  as: 

1.  Is  there  any  cue  or  action  that  must  precede  this  step? 

2.  Are  there  too  many  cues  in  the  task  step? 

3.  Is  that  step  always  performed  this  way? 
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4.  Is  there  an  alternative  to  this  step? 

5.  Is  the  observed  behavior  of  the  tested  user  more  typical  than  assumed 
in  the  step  details  ? 

6.  Is  this  the  quickest  sequence  of  task  steps  possible? 

7.  Has  all  available  support  equipment  been  fully  utilized  in  task  steps? 

The  completed  Task  Analysis  Worksheets  provide  a  synopsis  of  technically  accu¬ 
rate,  logical  steps  which  are  the  best  way  to  perform  the  task.  The  JPA  devel¬ 
oper  will  amplify,  refine  and  create  final  graphic  aids  from  the  complete  data 
base  developed  via  MTI&A. 

6.5. 1. 1  Hands-on  Equipment  Analysis.  The  equipment  is  the  only  completely 
reliable  source  of  information  about  itself.  As  the  development  of  task  steps 
and  step  description  for  the  worksheets  progresses,  the  analyst  must  gain 
regular  hands-on  access  to  the  system  or  equipment.  The  surest  way  to  ensure 
accuracy  and  completeness  is  to  eliminate  theorizing  and  guesswork  by  actually 
performing  tasks  such  as  making  checks  with  the  actual  test  equipment,  dis¬ 
assembling  a  hard-to-reach  assembly,  or  going  through  all  the  steps  of  a  com¬ 
plex  alignment.  The  hands-on  effort  gives  the  analysts  confidence  in  their 
familiarity  with  the  equipment,  which  is  usually  reflected  in  better  task  analysis 
and  decreased  development  time  for  MTI&A.  Later  in  the  analysis  process,  of 
course,  the  analyst  must  validate  all  of  the  worksheet  data  and  other  MTI&A  prod' 
ucts  on  the  actual  equipment.  The  analysts  will  find  validation  a  much  simpler 
process  if  the  task  worksheet  data  have  been  tried  out  on  the  equipment  through¬ 
out  development. 

6.5. 1.2  Level  of  Detail  in  Step  Descriptions.  The  analyst  should  ensure  that  for 
each  task  and  subtask  the  worksheet  includes  only  the  simplest,  briefest,  and 
most  straightforward  and  efficient  step  descriptions.  The  level  of  detail  of  the 
worksheet  step  descriptions  shall  be  consistent  with  the  level  recommended  in 
Figure  19,  Sheet  2  Item  14.  If  it  is  too  brief,  it  will  require  the  JPA  developer 
to  re-examine  the  data  thereby  repeating  the  research  efforts  of  the  task  analyst. 
If  it  is  more  detailed  than  the  sample,  the  analyst  will  have,  in  effect,  written 
the  JPA  procedures  and  that  is  not  the  purpose  of  the  MTI&A  process  or  the 
function  of  an  analyst.  The  data  called  for  in  the  worksheet  is  the  keystone  of 
the  MTI&A.  Step  descriptions  must  include  all  elements  of  the  procedure  and 
identify  all  of  the  cues  available  to  the  user  and  all  of  the  responses  the  user 
must  make.  Given  this  information,  the  JPA  developer  can  prepare  proce¬ 
dures  which  focus  on  the  cues  available  to  the  technician  and  explain  the 
responses  which  must  be  made.  The  task  analyst's  Job  is  to  make  certain 
that  all  of  the  information  required  to  write  the  procedure  in  accordance 

with  the  specification  is  in  the  data  base.  The  analyst  must  imagine  how  the 


technician  will  perceive  the  real  equipment  and  relate  to  it  using  the  JPA.  In 
writing  step  descriptions,  the  analyst  must  mentally  assume  the  place  of  the 
maintenance  technician  who  will  perform  the  task  in  the  field.  The  analyst  must 
visualize  performance  of  the  task,  conceptualize  the  JPA  that  will  be  prepared 
to  meet  the  stated  requirements,  and  then  judge  whether  the  needed  data  are  in 
the  data  base.  It  is  much  better  to  err  in  favor  of  providing  more  data  than  the 
JPA  developer  needs  than  the  costly  problem  that  would  develop  if  there  were 
not  enough  data.  Finally,  any  missing  information  must  be  obtained  and  in¬ 
cluded  to  complete  the  task  data  base. 

6.5. 1. 3  Illustrations.  The  analyst  must  attach  to  each  worksheet,  any  and  all 
illustrative  data  such  as  engineering  drawings,  diagrams,  sketches,  photo¬ 
graphs,  copies  of  pages  from  commercial  manuals,  or  combinations  of  these 
that  were  used  in  compiling  the  task  detail  analysis  and  worksheets.  The  ana¬ 
lyst  should  provide  sketches  of  settings,  physical  locations,  etc.,  that  are 
important  in  understanding  the  step  description.  The  analyst  should  annotate 
each  item  with  callouts,  lines,  notes,  sketches,  etc.,  as  appropriate.  Such 
data  may  be  applied  by  hand,  as  long  as  it  is  neat  and  legible.  Section  5.7. 1.3 
provides  guidelines  for  the  analyst  to  observe  when  developing  the  illustration 
package  that  must  accompany  each  Task  Analysis  Worksheet. 

6. 5. 1.4  Follow-on  Maintenance.  The  analyst  must  identify  all  maintenance 
actions  which  must  be  performed  after  the  subject  task.  Some  tasks  are  not 
complete  work  units  in  themselves.  When  the  goal  of  the  task  is  achieved,  the 
tasks  required  to  return  the  system/equipment  to  operational  readiness  or  safe 
condition  after  completion  of  the  task  shall  be  listed  in  this  item. 

6.6  Troublwhooting  Task  Analysis.  Since  this  phase  of  task  analysis  is  the  most 
demanding,  it  requires  the  best  qualified  people  (analysts)  anc'  dedicated  support 
to  the  analysis  (SMEs,  equipment  availability,  management  support,  etc.). 
Properly  planned,  supported,  and  carried  out,  this  phase  can  produce  a  cost- 
efficient,  complete,  and  accurate  troubleshooting  data  base  that  will  provide  the 
user  with  useful,  effective  Logic  Tree  Troubleshooting  Aid  JPAs  or  other  type 
manuals,  as  appropriate.  Aided  by  previously  developed  MTI&A  products,  the 
TIM,  the  Definitized  User  Profile,  the  Support  Equipment  Guide,  and  the  Level 
of  Detail  Guide,  as  well  as  system  functional  drawings,  and  a  knowledge  of  the 
system,  the  analyst  must  perform  a  Performance  Analysis  and  a  Failure  Mode 
and  Fault  ^mptom  Analysis.  The  products  of  these  troubleshooting  analyses 
are  as  follows; 


a.  Checkout  Summary 

b.  Fault  Symptom  List 

c.  Action  Trees 
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6.6.1  Overview.  The  analyst  begins  the  analysis  and  definition  of  checkout  and 
troubleshooting  tasks  by  examining  the  TIM  for  all  cells  coded  as  OL,  IL,  or  BL. 
These  codes  indicate  that  a  checkout  and  troubleshoot  task  has  been  identified  for 
the  equipment  component  and  that  it  is  a  candidate  for  checkout  or  troubleshooting 
at  O  or  I  level,  or  at  both  levels  (B).  The  letter  L  indicates  that  the  checkout  or 
troubleshooting  task  will  be  developed  for  the  LTTA  manual.  In  the  Performance 
Analysis,  the  analyst  must  identify  all  of  the  design  functions  of  the  subsystems 
and  equipment,  and  establish  the  checks  that  can  determine  if  these  functions  are 
performing  normally.  The  performance  analysis  also  establishes  the  measur¬ 
able  parameters  associated  with  each  function  and  each  component  that  contrib¬ 
utes  to  that  function.  Performance  parameters  are  the  range  of  acceptable  values 
that,  when  measured,  indicate  whether  or  not  the  component  (subsystem,  equip¬ 
ment,  assembly,  part)  is  operating  satisfactorily.  The  results  of  this  analysis 
are  recorded  on  a  Checkout  Summary,  Figure  34,  which  becomes  the  basis  for 
later  development  of  checkout  procedures  by  LTTA  preparers.  (Checkout  proce¬ 
dures  in  the  LTTA  are  used  to  test  whether  the  components  of  the  system  are 
functioning  properly  or,  if  not,  are  causing  fault  symptoms.)  Next,  the  analyst 
performs  a  failure  mode  and  fault  symptom  analysis  on  each  component  of  the 
system  identified  in  the  TIM  for  checkout  and  troubleshooting.  The  fault  ssrmp- 
tom  analysis  identifies  the  ways  in  which  each  component  function  can  fail  (its 
failure  modes)  and  cause  a  fault  and  a  related  fault  symptom.  This  analysis  pro¬ 
duces  a  list  of  fault  symptoms  for  each  failure  mode.  The  final  phase  of  trouble¬ 
shooting  task  analysis  is  the  development  of  an  AT  for  each  of  the  fault  symptoms 
on  the  list. 

6.6.2  Accomplishing  Performance  Analysis 

6.6.2. 1  Source  Data.  The  analyst  will  depend  on  a  number  of  data  sources  for 
troubleshooting  task  analysis,  but  few  are  as  important  as  solid  understanding 
of  the  theory  of  operation  of  the  system,  at  and  above  the  pertinent  level  of 
repair.  The  data  sources  for  performance  analysis  will  focus  on  those  that  per¬ 
mit  the  analyst  to  learn  the  functional  interrelationships  of  system  components, 
such  as  theory  of  operation  descriptions  and  diagrams  in  the  following; 

1.  Existing  Technical  Literature  —  Contractor  SMEs  should  be  able  to 
provide  such  technical  literature  in  the  form  of  commercial  operation  and  main¬ 
tenance  manuals,  or  if  the  equipment  has  been  previously  procured  for  military 
use,  then  Air  Force  Technical  Orders,  Army  Technical  Manuals,  etc.,  should 
be  available.  If  the  system  employs  equipment  or  major  assemblies  manufac¬ 
tured  by  other  companies,  commercial  manuals  are  usually  packed  with  each 
unit  shipped  to  the  prime  contractor.  If  not,  the  analyst  should  request  the  con¬ 
tractor  purchasing  agent  to  request  or  purchase  commercial  manuals.  MIL-spec 
manuals  often  provide  the  analyst  with  greater  detail,  so  it  is  helpful  to  query  the 
manufacturer  to  determine  if  a  military  manual  has  been  developed  on  the  com¬ 
ponent.  If  so,  order  it  through  your  contracting  office  or  technical  library. 


2.  Functional  Block  and  Schematic  Diagrams  —  If  the  system/equipment 

is  under  development  and  no  technical  literature  exists,  the  analyst  should  obtain 
electronic  and  mechanical  block  diagrams  that  show  the  organization  and  inter¬ 
relationships  of  units  from  the  design  engineering  personnel  or  from  the  manu¬ 
facturer.  Start  with  diagrams  used  in  catalogs,  data  sheets,  proposals,  etc. 

For  example,  many  technical  proposals  contain  such  drawings  showing  the 
system  components  and  their  inputs  and  outputs.  Engineering  design  usually 
begins  with  sketched  block  diagrams  and  schematics  outlining  the  equipment 
hierarchy.  Figure  35  is  a  sample  of  the  system  hierarchy  portrayed  in  a  func¬ 
tional  block  diagram. 

3.  Other  Data  —  The  analyst  will  also  need  more  detailed  information  in 
order  to  understand  the  system,  such  as  mechanical  layout  diagrams,  wiring 
lists,  written  functional  descriptions,  circuit  descriptions,  and  similar  data 
describing  signal  flow,  interdependencies,  operation,  and  performance  parame¬ 
ters.  Most  of  this  information  is  generated  in  some  form  by  engineers  to  explain 
to  other  supporting  departments  (Ic^istics,  manufacturing,  etc.)  the  makeup  of 
the  hardware.  Consult,  for  example,  functional  descriptions  in  purchasing  spe¬ 
cifications  that  are  written  to  procure  vendor  equipments  or  assemblies.  Many 
purchased  items  such  as  printed  circuit  boards,  power  supplies,  and  mechanical 
assemblies  are  selected  from  company  catalogs  that  contain  descriptions,  dia¬ 
grams,  and  test  data. 

6. 6. 2. 2  Learning  the  Siystem  Functional  Operation.  The  analyst  must  become 
familiar  with  all  of  the  source  data  and  quickly  determine  its  weaknesses  and 
data  gaps,  if  there  are  any.  If  the  data  are  inadequate  or  unreliable  or  if  the 
analyst  is  doing  performance  analysis  on  a  developing  system  with  little  formal 
data,  it  will  be  necessary  to  learn  the  system  or  equipment  functions  by  other 
means.  If  technical  data  exist  on  hardware  that  has  similar  functions  or  com¬ 
ponents,  the  analyst  should  assemble  data  on  and  study  those  parts  that  are  like 
the  subject  equipment.  The  analyst  should  then  analyze  the  functional  interrela¬ 
tionships  of  parts  by  assembling  and  stucfy^ing  engineering  drawings  or  sketches 
on  new,  undocumented  hardware.  After  that  the  analyst  must  complete  the  learn¬ 
ing  phase  by  interview  and  consultations  with  SMEs  to  obtain  the  knowledge 
necessary  to  prepare  a  complete  Checkout  Summary,  a  Fault  Symptom  List, 

and  complete  Action  Trees. 

6. 6. 2. 3  The  performance  analysis  is  developed  from  the  energy  flow  diagrams, 
functional  flow  block  diagrams,  schematics,  other  collected  source  data  that 
depict  the  functional,  organizational  hierarchy  of  the  system  and  the  interrela¬ 
tionships  among  all  components.  The  analyst  should  assemble  all  such  drawings 
until  all  maintenance  significant  components  (significant  at  Organizational  or 
Intermediate  level,  as  appropriate)  in  the  entire  system  or  equipment  are  rep¬ 
resented.  Figures  23,  26,  27,  and  35  are  samples  of  the  types  of  engineering 
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drawings  and  data  required  for  this  task.  Make  certain  by  checking  off  each 
TIM  component  to  show  that  there  is  coverage  for  that  item  at  the  pertinent  func¬ 
tional  level.  If  each  assembly  on  the  block  diagram  is  checked  against  the  TIM, 
a  complete  functional  picture  is  assured.  At  each  new  level  of  subdivision,  all 
parts  or  assemblies  must  be  accounted  for  on  the  drawings  and  checked  against 
the  TIM.  Make  certain  that  all  the  components  related  to  cells  of  the  TIM  that 
are  marked  for  OL,  IL,  or  BL  can  be  identified  on  the  assembled  drawings.  For 
each  such  TIM  component,  annotate  the  drawing  to  show  the  measurable  perform¬ 
ance  parameters  for  that  component  (such  as  24  Vdc;  ±1.2  Vdc;  or  horizontal 
scan  =  5  (±  .  15)  inches.  Figure  23  shows  a  diagram  that  the  analyst  has  neatly 
annotated  to  show  the  performance  parameters  of  important  functional  compo¬ 
nents.  The  waveforms  and  voltage  levels  were  selected  by  the  analyst  during 
performance  analysis  because  the  TIM  indicated  that  these  components  were 
appropriate  for  checkout  and  troubleshooting  tasks.  The  analyst  obtained  the 
test  data  from  an  SME,  and  marked  it  on  the  functional  flow  diagram  to  indicate 
that  if  these  readings  and  waveforms  are  tested  as  shown,  they  will  indicate 
whether  or  not  the  unit  is  operating  normally. 

The  analyst  checks  the  accuracy  of  these  annotated  performance  parameters  by 
testing  them  with  appropriate  test  equipment  on  the  actual  system  hardware  or 
by  visualizing  etc. ,  as  the  check  requires.  After  each  is  tested  and  if  necessary 
corrected,  the  analyst  has  a  complete  set  of  source  data  drawings  which  con¬ 
tain,  for  each  TIM  cell  marked  for  Checkout/Troubleshoot,  a  measurable  or 
observable  parameter  consisting  of  input  or  output  measurements,  observable 
indications,  panel  readings,  etc.  The  analyst  should  include  in  the  annotations 
information  concerning  test  equipment  to  be  used,  waveshapes,  voltage  levels, 
references  to  test  diagrams  or  other  observations.  These  drawings  will  be  used 
as  follows; 

a.  To  develop  the  Checkout  Summary 

b.  To  aid  the  analyst  in  AT  preparation 

c.  To  be  retained  throughout  the  program  and  carefully  updated  with 
every  change 

d.  To  be  made  available  to  the  government  during  in-process  review, 
validation,  etc. 

e.  To  aid  the  JPA  developer  in  checkout  and  logic  tree  preparation. 

These  drawings  will  provide  a  detailed  record  of  the  performance  analysis  for 
troubleshooting  and  an  audit  trail  for  government  reviewers.  For  these  rea¬ 
sons  the  drawing  annotations  must  be  neat  and  legible  as  exemplified  in  Figures 
23  and  25. 
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6,6,3  Checkout  Summary.  The  analyst  shall  develop  a  summary  of  all  observ¬ 
able  performance  parameters  on  the  diagrams  in  a  Checkout  Summary  as  shown 
in  Figure  34.  One  or  more  separate  Checkout  Summaries  should  be  developed 
for  each  diagram  annotated  during  performance  analysis.  Enter  the  name  of 
the  component  (e.g. ,  Detection  Subsystem)  and  include  the  reference  desig^nator 
from  the  TIM,  if  the  item  has  one. 

6.6.3. 1  Checks  Column.  Using  the  information  annotated  on  the  drawings,  pre¬ 
pare  a  list  of  checks  that  must  be  made  to  test  performance  of  each  component 
listed  for  Checkout  on  the  TIM,  including  any  data  to  be  used  in  the  check.  As 
each  check  is  entered  on  the  Checkout  Summary,  mark  the  appropriate  TIM  cell 
to  indicate  that  the  Checkout  entry  has  been  satisfied.  A  completely  checked-off 
TIM  is  assurance  that  the  Checkout  Summary  is  complete. 

6. 6. 3. 2  Performance  Parameters  Column.  This  column  must  include  param¬ 
eters  for  each  mode  of  operation  in  which  observations  or  tests  can  be  made  and 
the  range  over  which  they  can  safely  vary.  The  parameters  to  be  listed  should 
include  all  indicators  of  performance  that  are  necessary  to  be  tested.  For 
example,  in  Figure  34,  the  second  item  listed  for  the  Detection  Subsystem  is  to 
see  that  the  Wide  Scan  Mode  checks  out  acceptably.  To  do  so,  the  user  must 
satisfy  the  following; 

a.  Check  that  the  Control  position  is  okay  (by  checking  that  WIDE  light 
is  on). 

b.  Check  that  the  Antenna  Scan  position  is  okay  (by  checking  that  the 
resolver  output  reading  is  85  (±  1.5)  degrees). 

c.  Check  that  the  Indicator  presentation  is  okay  by  testing  that; 

(1)  The  horizontal  scan  is  5  (±  .15)  inches 

(2)  The  vertical  scan  is  4  (±  .1)  inches 

(3)  There  is  a  transmitter  pulse  present 

(4)  There  is  target/clutter  video  present. 

As  suggested  in  the  specification,  the  Checkout  Summary  need  not  be  typed,  but 
if  it  is  not,  it  should  be  neatly  handwritten  and  kept  up  to  date  throughout  MTI&A. 

6.6.4  Failure  Mode  and  Fault  ^mptom  Analysis.  For  this  analysis,  the  analyst 
should  utilize  the  TIM,  the  Checkout  Summary,  and  the  drawings  assembled  for 
performance  analysis.  To  develop  the  failure  modes  and  fault  symptoms,  identify 
the  ways  (modes)  in  which  each  major  function  depicted  on  the  performance  analy¬ 
sis  drawings  can  fail.  Each  of  these  failure  modes  can  cause  a  fault  and  symptoms 
for  that  fault. 
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The  analyst  should  check  each  item  or  component  in  the  TIM  that  is  coded  for 
checkout  and  troubleshoot  and  make  certain  there  is  a  related  performance  par¬ 
ameter  that  has  been  recorded  on  functional  drawings.  That  is,  ensure  there  is 
something  to  test  for  each  component  that  is  to  be  checked  out  or  fault  diagnosed. 

For  each  component  checked  for  Checkout  or  Troubleshoot  task  in  the  TIM,  the 
analyst  should  ask  questions  such  as  the  following  to  determine  the  component's 
failure  modes  and  the  characteristics  of  each: 

1.  How  many  ways  can  this  component  fail? 

2.  Will  each  level  of  failure  have  a  distinct  effect  on  documentation 
components? 

3.  What  can  happen  when  this  component  completely  fails? 

4.  What  can  happen  when  it  is  operating  but  in  a  degraded  condition? 

5.  What  can  happen  if  this  component  fails  during  operation  mode  a? 

During  other  modes? 

6.  Can  this  component  fail  intermittently? 

7.  What  can  happen  during  intermittent  failures? 

6.6.5  Fault  Symptom  List.  The  analyst  must  develop  from  the  Failure  Mode 
and  Fault  Symptom  Analysis,  a  list  of  Fault  ^mptoms  appropriate  to  the  sys¬ 
tem  (an  example  is  shown  in  Figure  37).  The  list  must  include  the  symptoms 
of  each  failure  mode  of  each  component  in  the  Checkout  Summary  including  test¬ 
ing  or  checking  details  and  such  indications  as  meter  readings,  sounds,  or  other 
cues  from  the  Checkout  Summary  Performance  Analysis  drawings.  Whenever 
possille,  the  analyst  should  create  the  failure  mode  on  the  system  by  inserting 
faults,  observing,  and  listing  each  symptom. 

The  analyst  must  prepare  a  separate  Fault  Symptom  List  for  each  operational 
mode  of  the  system  or  equipment,  where  each  mode  creates  different  fault 
symptoms. 

6.6.6  Action  Trees.  An  Action  Tree  (AT)  shall  be  developed  for  each  fault 
symptom  identified  on  the  Fault  Symptom  List.  An  action  tree  is  a  branching 
tree  outline,  or  block  diagram,  of  the  components,  assemblies,  or  equipments 
that  can  cause  the  fault  symptom,  together  with  procedural  information  neces¬ 
sary  for  later  use  by  the  LTTA  developer  in  explaining  diagnostic  procedures. 
The  title  of  the  AT  is  the  fault  symptom  it  addresses  and  diagnoses. 


6.6.6. 1  Developing  the  Troubleshooting  Logic.  The  analyst  should  construct  the 
action  tree  from  those  components  in  the  TIM  that  can  contribute  to  the  fault 
symptom  involved.  The  AT  must  be  prepared  fjrom  a  basic  knowledge  of  the 
logical  hierarchy  of  components,  as  in  Figures  38  and  39,  together  with  a  modi¬ 
fied  half-split  fault  isolation  technique.  The  AT  procedure  must  optimize  the 
following  technician  considerations  to  ensure  that  minimum  fault  isolation  time 
has  been  achieved: 

a.  Time  to  gain  access  to  the  component 

b.  Time  to  test  the  component 

c.  Reliability  of  parts  involved  and  of  replacement  parts 

d.  Requirements  of  tools  and  test  equipment  to  be  used 

e.  Modified  half-split  troubleshooting  logic  (explained  below). 

Action  trees  should  contain  a  synopsis  of  all  essential  and  pertinent  information 
that  will  be  needed  by  the  JPA  developer  to  prepare  a  LTTA  from  the  AT  and 
other  MTI&A  products.  This  includes  warnings,  cautions,  notes,  power  turn¬ 
on  procedures,  pre-checkout  procedures,  reference  diagrams,  initial  switch 
settings,  etc.  Each  AT  should  be  prepared  assuming  only  one  malfunction  at  a 
time  is  being  addressed  and  the  arrangement  of  components  must  be  in  the  order 
of  their  importance  as  most  probable  causes  of  the  fault.  Selection  of  support 
equipment  must  be  limited  to  those  items  found  in  the  Support  Equipment  Guide. 
The  first  step  in  developing  the  logic  of  the  AT  is  to  develop  a  schematic  repre¬ 
sentation  of  the  functional  relationships  among  components  in  the  system ,  a  block 
diagram  that  depicts  the  relationships  among  all  of  the  components  listed  as  pos¬ 
sible  causes  of  the  fault  symptom  for  which  the  AT  will  be  prepared.  Eliminate 
from  the  diagram,  components  that  cannot  contribute  to  the  fault  so  as  to  keep 
the  troubleshooting  logic  as  simple  as  possible.  From  this  hierarchy  of  com¬ 
ponents,  develop  the  tree  branches  by  choosing  test  instrument,  type  of  test,  and 
location  of  test,  and  diagnostic  tests  which  will  determine  the  best  branch  of  the 
tree  to  follow,  the  possible  outcome  of  each  test,  and  the  action  to  be  taken  as  a 
result  of  each  test.  In  summary,  develop  the  AT  so  that  it  provides  a  synopsis 
of  the  most  logical,  orderly  troubleshooting  sequence  that  provides  the  fastest 
route  to  fault  diagnosis. 

6. 6. 6. 2  Modified  Half-Split  Troubleshooting  Strategy.  Selection  of  the  best 
branch  to  perform  a  troubleshooting  test  is  of  primary  importance.  Test  bran¬ 
ches  should  be  selected  in  such  a  way  as  to  divide  all  of  the  suspect  components 
for  the  fault  symptom  on  the  block  diagram  into  two  equal  groups  (as  nearly  as 
possible).  For  the  component  block  diagram  shown  below,  if  all  components 
have  equal  failure  probability  and  are  equally  accessible,  the  first  test  location 
would  be  at  point  A  since  the  choice  permits  dividing  the  components  most  nearly 


in  half.  No  other  test  point  permits  better  than  an  8-3  split.  If  a  "good  "  indica¬ 
tion  is  found  at  A,  the  second  test  should  be  at  B  or  C.  If  a  "bad  "  indication 
is  found  at  A,  the  second  test  should  be  at  D.  Each  check  eliminates  about  half 
of  the  components  from  consideration.  These  components  are  known  to  be  "good. " 
The  choice  of  test  location  between  die  suspect  components  should  be  such  that 
the  check  be  made  at  the  mid-point  of  the  chain,  and  each  succeedii^  check  be 
made  at  the  mid-point  of  the  remaining  portion  of  the  chain.  Thus,  assuming 
each  component  has  an  equal  probability  of  failure,  the  branching  proceeds 
halving  the  probabilities  that  the  malfunctioning  component  lies  on  one  side  or 
the  other  of  the  check.  This  strategy  defines  the  half-split  technique  of  trouble¬ 
shooting. 


The  pure  half-split  technique  described  above  is  seldom  the  most  economical  for 
100  percent  of  the  checks,  because  of  practical  constraints.  The  half-split 
strategy  should  be  modified  by  introducing  the  following  considerations: 

a.  Reliability.  Checks  for  items  with  high  failure  rates  should  precede 
checks  for  items  with  lower  failure  rates. 

b.  Accessibility.  Checks  that  are  "quick  and  easy  "  should  precede  those 
that  involve  extensive  or  time-consuming  disassembly.  The  best  AT  from  a 
user's  standpoint  is  one  that  finds  the  trouble  in  the  shortest  time. 

c.  Probability  of  Malfunction  Introduction.  Those  checks  which  involve 
activities  with  high  probability  of  accidental  malfunction  introduction  should  be 
deferred  toward  the  end  of  the  procedure.  Whenever  a  static  check  (power  off) 
and  a  (fynamic  check  can  reveal  roughly  the  same  diagnostic  information,  the 
static  check  is  preferred. 
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d.  Location  of  the  Technician.  Other  things  being  equal,  the  sequence  of 
checks  should  minimize  the  movement  of  the  technician  from  one  location  to 
another. 

e.  Test  Equipment  Setup.  An  unusually  time-consuming  test  equipment 
setup  should  be  weighed  against  the  information  it  can  provide  to  consider  whe¬ 
ther  its  use  would  be  presented  earlier  or  later  in  the  check  sequence. 

The  analyst  must  include  procedural  step  data  in  the  AT  where  changes  in  equip¬ 
ment  condition  are  required  to  permit  a  check,  when  method  of  access  must  be 
specified,  or  when  test  equipment  settings  must  be  specified. 

Include  a  corrective  action  step  at  the  end  of  each  branch  of  the  AT,  and  identify 
any  follow-on  or  related  tasks  (e.g. ,  return  to  checkout)  that  the  LTTA  developer 
should  know. 

6. 6. 6. 3  Action  Tree  Data.  Action  trees  shall  contain  the  following  information: 

a.  Brief  procedural  steps  that  will  provide  the  LTTA  developer  with 
technical  guidelines  on  developing  the  checkout  and  logic  tree  trouble¬ 
shooting  for  operations  where  no  decision  is  required,  such  as  in 
Figure  39.  In  the  statement  "Check  air  pressure  for  35  psig  and 
engine  rotating  at  28-34%,"  the  analyst  provides  data  for  the  LTTA 
developer  to  use  as  source  data  in  preparing  detailed  Logic  Tree 
test/decision  boxes. 

b.  Repair  or  replacement  steps,  which  direct  the  repair  or  replacement 
of  a  faulty  component.  The  component  to  be  repaired  or  replaced 
should  be  identified  by  the  same  nomenclature  or  reference  designator, 
as  listed  in  the  TIM. 

c.  Decision  branches  in  the  tree  should  identify  the  diagnostic  tests  to  be 
made,  the  possible  outcomes,  and  the  action  to  be  taken  as  a  result  of 
each  outcome.  Make  certain  that  the  following  data  are  included: 

(1)  Name  and  model  number  of  test  instrument  (if  any) 

(2)  Type  of  reading  (e.g.,  pressure,  voltage) 

(3 )  Location  of  test  points 

(4)  Range  of  acceptable  values  for  the  reading 

(5)  Action  to  take  as  a  result  of  each  possible  outcome  of  the  check. 
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6.6. 6. 4  Action  Tree  Development  Rules.  The  analyst  shall  develop  each  AT 
according  to  the  following  rules  and  strategies.  Refer  to  Figure  39  for  applica¬ 
tion  of  these  rules  to  a  sample  action  tree  that  an  analyst  would  have  developed. 
Letter  callouts  in  the  rules  below  refer  to  those  on  the  sample  figure. 

a.  Only  one  fault  symptom  is  observable  at  a  time  and  only  one  fault  exists 
in  the  system  at  a  time. 

b.  Each  point  of  test  shall  be  selected  to  obtain  the  greatest  amount  of  fault 
isolation  information  for  the  action  taken  (i.e. ,  the  modified  half-split  strategy). 
Instructions  for  performing  the  test  shall  be  concise,  simply  worded,  and  arran¬ 
ged  in  specific  steps  (see  A).  The  analyst  shall  make  reference  from  the  test 
steps  to  an  attached  drawing  or  other  reference,  for  physical  identification  and 
location  of  components  involved  (see  B). 

c.  When  a  test  result  shows  that  the  fault  does  not  lie  in  a  specified  section 
of  the  system ,  the  branch  of  the  tree  representing  that  section  should  not  be 
accessible  for  later  trouble  isolation  tests  (i.e. ,  no  further  testing  is  permitted 
in  that  section  of  the  system)  (see  B). 

d.  The  first  tests  to  be  done  will  normally  be  those  that  use  meters, 
switches,  annunciators,  warning  lights,  and  other  built-in  test  equipment.  The 
human  senses  for  sight,  sound,  and  touch  should  also  be  used  to  advantage  in  the 
testing  process. 

e.  Tests  that  must  be  done  with  external  test  equipment  will  normally 
appear  later  in  the  testing  process. 

f.  Two  or  more  tests  shall  not  cause  a  closed  loop  in  the  strategy  (i.e. , 
a  situation  wherein  one  fault  is  isolated  from  two  branches  of  the  action  tree). 

g.  No  test  shall  result  in  a  dead  end  (i.e. ,  a  situation  in  which  the  LTTA 
developer  is  left  to  devise  a  strategy  for  continuing  the  trouble  isolation  pro¬ 
cedure  ) . 

h.  Every  test  must  yield  a  reliable  result  compatible  with  a  "yes"  or  "no" 
question.  There  shall  be  no  possibility  of  a  third  ambiguous  result. 

i.  A  serial  (nonbranching)  sequence  in  which  one  item  after  another  is 
checked  for  a  pass/ fail  condition  until  the  fault  is  found  (as  in  doing  a  Checkout) 
is  permissible  only  where  it  is  the  only  possible  sequence  for  testing. 


j.  The  tests  in  each  branch  shall  result  in  accomplishing  one  of  the  following, 
as  applicable  to  the  respective  maintenance  level  and  authorized  maintenance 
procedures: 

(1)  Determine  which  one  of  two  components  is  faulty. 

(2)  Determine  that  a  component  is  faulty  or  that  an  additional  test 
must  be  made. 

(3)  Determine  that  further  checkout  or  test  must  be  made. 

k.  Each  AT  test  instruction  shall  provide  the  LTTA  developer  with  enough 
information  to  develop  complete  l(^c  tree  Instructions  (see  C). 

l.  Corrective  action  instructions  at  the  ends  of  the  branches  shall  include  both 
the  corrective  action  to  be  taken  and  the  follow-on  to  be  done  (see  D). 

m.  Corrective  action  instructions  shall  include  one  of  the  following  as 
required  actions: 

(1)  Repair,  replacement,  adjustment,  or  alignment  of  a  specific  unit, 
part,  or  piece  (see  E). 

(2)  Further  testing  of  the  assembly  or  subassembly  to  further  isolate 
the  fault  (see  F). 
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6,6.6. 5  Action  Tree  Format.  The  specification  permits  any  format  that  pro¬ 
duces  a  well  organized  AT  structure  and  is  logical,  legible,  and  complete.  The 
same  AT  in  Figure  39  would  be  acceptable  in  its  neatly  handwritten  format. 


7.  QUALITY  ASSURANCE  OF  MTIAA 

7.1  Quality  Awurance  Plan,  The  Quality  Assurance  Plan  described  in  this  section 
must  be  developed  at  the  outset  of  the  MTI&A  planning  phase  and  become  a  coor¬ 
dinated  part  of  the  Task  Analysis  Plan  descril^d  in  the  Draft  ^>ecification, 
AFHRL-TR-79-50,  Section  3. 1.3.  The  purpose  of  the  Quality  Assurance  Plan 
is  to  assure  the  Acqiiisition  agency  that  tte  contractor  has  all  of  the  requisites 
for  a  thorough  and  successful  BfTI&A  development  program.  As  emphasized 
throughout  this  handbook,  the  specification  requires  significantly  greater  dis¬ 
cipline  and  depth  of  detail  than  is  required  in  planning  and  developing  conven¬ 
tional  technical  manuals.  Consequently,  even  a  quality  assurance  organization 
that  is  experienced  in  controlling  conventional  military  technical  manual  pro¬ 
grams  may  require  considerable  organizational  and  procedural  adjustment  in 
order  to  control  the  quality  and  technical  integrity  of  MTI&A  programs.  If  the 
contractor  does  not  have  an  ongoing  QA  capability  for  technical  data  programs, 
Ae  task  of  assembling  one  which  will  satisty  all  contractual  requirements  and 
ensure  its  success  is  a  substantial  one.  The  Quality  Assurance  Plan  will  be 
given  serious  consideration  by  the  Acquisition  agency,  because  it  reflects  the 
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contractor's  knowledge  and  capability  to  perform  the  complex  task  analysis. 
Plans  that  are  too  general  in  content  to  address  the  specific  quality  control 
problems  of  task  analysis  may  suggest  a  lack  of  attention  or  understanding  by 
a  contractor  concerning  the  importance  of  quality  assurance.  Such  plans  may 
be  considered  unacceptable  by  the  Acquisition  agency.  If  the  contractor  does 
not  have  a  formal  QA  structure,  the  QA  Plan  must  provide  substantive  detail  in 
explaining  the  contractor's  understanding  of  the  specification  and  its  require¬ 
ments  for  data  quality  and  completeness.  It  must  ^plain  how  the  contractor 
will  select  personnel  to  perform  QA  on  task  analysis,  their  background  for  the 
assignment,  and  the  organizational  support  they  will  receive.  To  ensure  against 
costly  false  starts,  the  QA  Plan  should  be  reviewed  and  approved  by  the  Acqm- 
sition  agency  before  the  research  and  task  analysis  begin. 

Copies  of  the  approved  plan  should  be  distributed  to  all  potential  QA  participants 
so  that  they  can  become  familiar  with  their  expected  role.  Copies  should  also 
go  to  task  analysts  so  they  know  the  inspection  criteria  for  task  analyses  and  the 
products  of  the  analyses. 

7.2  Quality  Assurance  Organization,  Ideally,  a  contractor  should  have  an  existing 
QA  function  that  is  an  arm  of  management  and  is  independent  of  the  department 
responsible  for  task  analysis.  The  QA  function  ensures  that  problems  of  quality 
and  accuracy  are  found  and  corrected  early  enough  to  forestall  schedule  delays 
and  cost  increases;  i.e. ,  long  before  th^  appear  in  a  deliverable  document.  In 
this  way,  the  contractor  ensures  that  products  will  reflect  a  constant  level  of 
high  quality  and  technical  accuracy.  A  QA  organization  will  prove  inadequate  if 
it  is  oriented  toward  random  surface  checks  or  sampling  the  data  for  minor 
inconsistencies  and  errors.  In  order  to  forestall  quality  and  accimacy  problems, 
a  contractor  should  review  the  type  of  technical  data  work  its  QA  function  nor¬ 
mally  controls  and  compare  their  normal  findings  with  the  detailed  specification 
and  review  requirements  set  forth  in  the  specification  and  this  handbook.  For 
example,  doet*  QA  normally  check  and  control  LSAR  data  outputs  when  it  is 
required  by  contract?  If  they  do  perform  in-depth  checking  of  LSAR,  they  may 
be  well  qualified  to  perform  MTI&A  QA. 

The  specification  does  not  require  rigid  formatting  of  MTI&A  products.  Instead, 
it  requires  a  technical  integrity  and  completeness  which  must  be  the  guideline 
for  QA  tasks. 

It  is  important  that  personnel  who  will  review  the  technical  quality  and  accuracy 
be  interested  more  in  the  technical  substance  of  data  than  in  cross-referencing 
errors  and  typing  errors.  Checks  for  technical  quality  require  that  the  reviewer 
care  about,  for  example,  completeness  of  the  TIM,  the  accuracy  of  the  reader 
profile,  the  maintenance  concept,  the  appropriate  tools  to  be  used,  and  the  most 
logical  approach  to  troubleshooting.  Some  QA  reviewers  are  satisfied  with  their 
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contribution  when  th^  find  any  kind  of  error.  If  their  time,  however,  is  taken  up 
by  inspecting  for  trivia,  a  review  for  substance  sometimes  occurs  only  at  valida¬ 
tion  or  verification,  and  that,  of  course,  is  much  too  late  in  the  c^cle  to  be 
learning  that  the  task  anafysis  has  serious  technical  deficiencies. 

The  QA  staff  should  include  well  qualified  technical  personnel  who  can  assess 
the  technical  validity  of  data  means  of  review  of  the  prelim inaiy  products, 
even  in  the  early  stages  of  development.  It  may,  for  example,  prove  necessary 
to  temporarily  assign  a  cognizant  engineer  to  the  QA  function  in  order  to  ensure 
accuracy  of  early  efforts,  such  as  the  TIM  and  the  Support  Equipment  Guide. 

Such  a  technical  reviewer  should  be  knowledgeable  of  the  equipment  and  its  main¬ 
tenance  philosophy  (test  equipment,  logistics  siqiport,  user,  etc. )  and  should  be 
capable  of  detecting  technical  inconsistencies  and  misconceptions. 

Personnel  assigned  to  quality  assurance  must  be  familiar  with  the  entire  task 
analysis  process  and  know  the  purpose  of  each  product  and  its  effect  on  final 
accuracy,  correctness,  and  completeness. 

7.3  Quality  Control  Forms.  Quality  assurance  personnel  must  be  able  to  commu¬ 
nicate  their  corrections  and  critiques  to  the  analyst  in  such  a  way  that  the  types 
of  errors  will  not  recur  in  future  analyses.  Reviewers  who  find  quality  and 
accuracy  problems  should  not  only  explain  the  inaccuracies  and  return  them  to 
the  originator's  si^ervisor  but  should  also  recommend  the  way  that  t7pe  of  error 
could  be  permanently  eliminated.  For  example,  QA  Review  Evaluation  Guide 
forms  are  simple  to  fill  out  but  th^  expose  and  record  recurring  quality  de¬ 
ficiencies.  Figure  41  is  a  sample  of  a  form  that  can  be  effectively  used  by  QA 
reviewers.  QA  reviewers  should  refuse  to  accept  material  for  review  that  has 
not  been  checked  for  accuracy  and  completeness  and  approved  by  the  analyst's 
supervisor. 

7.4  Technical  Quality  Control.  The  output  of  the  task  analysis  effort  is  a  set  of 
products  that  must  be  thoroughly  reviewed  for  technical  accuracy,  consistency, 
and  completeness  before  submission  for  in-process  review,  validation,  or 
delivery, 

MTI&A  products,  therefore,  are  the  method  by  which  the  analyst  organizes  the 
logical,  accurate  approach  to  the  problems  of  maintenance.  The  efforts  of  ana¬ 
lysts  in  preparing  the  products,  such  as  the  TIM,  User  Profile,  Support  Equip¬ 
ment  Guide,  Level  of  Detail  Guide,  Task  Analysis  Worksheets,  and  if  required. 
Checkout  Summary,  Fault  Sjymptom  List,  and  Action  Trees  must  be  reviewed 
for  technical  quality  while  they  are  in  progress.  The  role  of  task  analysis  and 
preparation  of  intermediate  products  is  first  to  ensure  the  in-depth  study  neces¬ 
sary  to  complete^  define  and  design  the  maintenance  and  troubleshooting  tasks. 


.  w'  a-  .o.  a .  ■ : 
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'MT'I&A  QA  Review  Evaluation  Oiide 

Subavatem/Eauioment  Reviewer(a) 

Date 

Reviewer — hiitial 
and  Date 

Cuatomer 

Review  Taak 

YES 

NO 

NA 

Approved? 

Comment 

1. 

TIM  was  prepared  lAW  approved  Syatem  GAPL, 
or  other  formal  parta  breakdown. 

2. 

TIM  includee  all  replaceable  componenta  deaig- 
nated  for  Organizational  and/or  Intermediate 

Level. 

3. 

TIM  reference  deaignatora,  codea,  and  part 
deacriptiona  are  accurate,  complete,  and  comply 
with  3. 2. 1. 1. 

4. 

Maintenance  taak  deciaiona  in  each  TIM  cell  are 

3.2. 1.3. 

5. 

Support  Equipment  Guide  ia  baaed  only  on  cua- 
tomer-approved  equipment. 

6. 

Standard  Statementa  developed  for  each  teat 
equipment  function  lAW  3. 3. 2.  S. 

7. 

If  LSA  ia  required  by  contract,  the  TIM  reflecta 
the  appropriate  LSAR  data  aheeta  aa  in  3. 5. 

8. 

Each  ?  in  ttie  TIM  haa  been  eliminated  aa  in  3.2. 1.4. 

9. 

The  Deflnltized  Uaer  ProflIe  reflecta  government- 
generated  Preliminary  Uaer  Profile  plua  contractor 
recommendatlona. 

10. 

The  Level  of  Detail  Guide  reflecta  foe  approved 
Definltlzed  Uaer  Profile. 

11. 

The  Level  of  Detail  (kiide  reflecta  typical  taak 
acttona  aa  in  3.3.3.1  aa  well  aa  all  ofoera  appro¬ 
priate  to  foe  ayatem  technologlea  and  aklll  require¬ 
ment. 

12. 

The  Taak  Analyala  Workaheeta  contain  all  data 
including  attached  illuatrationa  aa  required  by 

3. 3. 4.1. 

13. 

A  Taak  Analyaie  Wsrkaheet  haa  been  prepared  for 
every  "X'  entry  in  foe  TIM. 

FIGURE  41.  QA  review  evaluation  guide  (sheet  1  of  2), 
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and  then  to  form  the  basis  for  day-to-day  technical  review  of  the  data.  The 
quality  control  reviewer  should  use  the  QA  Review  Evaluation  Guide  (Figure  41 ) 
to  ensure  that  task  analysis  and  the  preparation  of  products  have  been  performed 
with  technical  thoroughness,  completeness,  and  compliance  with  the  specification. 

7.5  Validation.  The  specification  (AFHRL-TR-79-50)  defines  validation  as  the 
process  by  which  the  contractor  ensures  the  adequacy,  accuracy  and  complete¬ 
ness  of  the  MTI&A  products  and  their  suitability  for  the  intended  purpose. 
Procedural  data  are  validated  by  actual  performance  on  the  subject  system/ 
equipment,  while  non-procedural  data  are  validated  by  such  methods  as  com¬ 
parison  with  source  data,  analysis  by  experts,  etc.  Validation  is  essentially 
a  Quality  and  Accuracy  Assurance  function  by  means  of  which  the  contractor 
gains  assurance  that  what  has  been  developed  to  comply  with  the  specification 
is  complete  and  accurate,  and  represents  a  quality  product.  The  contractor's 
Quality  Assurance  department  should,  therefore,  schedule,  organize,  and  moni¬ 
tor  the  entire  validation  process.  A  quality  assurance  inspector  should  be  a 
member  of  the  validation  team  throughout  the  validation  process  to  ensure  that 
it  is  proceeding  in  accordance  with  all  contract  requirements,  including  4.6  of 
the  MTI&A  specification.  The  members  of  the  validation  team  should  be  alert 
to  prevent  the  deterioration  of  the  validating  effort  if  it  should  last  for  many 
days.  Sometimes  when  validation  is  a  lengthy  process  and  the  same  team  mem¬ 
bers  participate  throughout,  there  is  a  tendency  to  assume  the  correctness  of 
some  of  the  task  data  base  rather  than  actually  testing  it. 

7.5. 1  Preparing  for  Validation.  Good  planning  is  essential  to  a  successful  vali¬ 
dation.  Planning  and  preparation  should  consist  of  the  following  steps; 

a.  Consult  the  approved  validation  plan  in  the  Task  Analysis  Plan  (speci¬ 
fication  3.1.3).  If  any  changes  are  anticipated  that  change  the  schedule,  con¬ 
ditions,  personnel,  etc.,  advise  the  Acquisition  agency  before  proceeding. 

b.  Make  certain  that  each  product  to  be  validated  is,  in  fact,  complete  and 
ready  for  review.  The  product  should  be  checked  for  completeness,  accuracy, 
and  compliance  with  the  specification  before  proceeding. 

c.  Determine  that  the  equipment  involved  is  in  its  normal  operating  mode 
(i.e. ,  functioning  properly,  properly  aligned,  etc. )  and  reserved  for  the  valida¬ 
tion  team  during  specific  periods. 

d.  Determine  that  all  support  equipment  (e.g. ,  test  equipment,  tools,  and 
interfacing  subsystems)  are  assigned  and  operable.  Test  equipment  should  be 
checked  for  calibration  before  being  used. 


e.  Notify  the  Acquisition  agency  of  the  date  and  place  of  validation  at  least 
45  days  in  advance  of  validation,  unless  otherwise  specified  by  the  contract  so 
that  the  government  reviewers  can  witness  validation,  if  they  so  desire. 

f.  Assign  and  schedule  the  participants  of  the  contractor's  validation  team 
(see  Section  7.5.6  of  this  handbook)  well  in  advance  so  that  they  will  be  com¬ 
mitted  to  the  validation. 

g.  Prepare  and  circulate  a  detailed  agenda  for  the  validation.  The  agenda 
should  provide  fairly  detailed  scheduling,  such  as:  "From  9:00  AM  to  12:00  PM  — 
Validate  'Detection  Subsystem  Task  Worksheets'." 

h.  Obtain  the  Validation  Record  forms  from  the  contracting  officer  and 
have  them  available  for  signature  ly  the  contractor  and  the  government  person¬ 
nel.  Validation  Records  are  explained  in  the  Data  Item  Description,  DI-M-3408. 

7.5.2  Validation  of  the  TIM.  The  TIM  should  be  validated  before  the  analyst 
proceeds  to  develop  the  Task  Detail  Analysis  and  Task  Analysis  Worksheets. 

To  validate  the  TIM  the  contractor  should  address  the  following: 

a.  Does  the  content  of  the  TIM,  the  hardware  organization,  maintenance 
codes,  and  maintenance  functions  agree  with  the  maintenance  concept  and  the 
specification? 

b.  Is  the  TIM  complete?  Does  each  matrix  cell  contain  an  appropriate 
entry,  and  are  all  hardware  items  from  the  data  base  (such  as  Illustrated  Parts 
Breakdown  (IPB),  Repair  Parts  and  Special  Tools  List  (RPSTL),  provisioning 
list,  LSAR  report)  listed? 

c.  Is  the  TIM  accurate?  Compare  the  hardware  breakdown  level  in  the 
TIM  with  the  original  document  and  show  that  they  are  identical. 

For  each  cell,  the  subject  matter  expert  should  check  if  the  listed  maintenance 
function  is  accurate  for  that  component  and  if  the  entry  indicates  the  appropriate 
level  of  maintenance. 

The  reviewer  should  check  all  empty  cells  and  consider  the  following  questions: 

a.  Why  isn't  there  a  maintenance  function  for  that  item? 

b.  Is  the  function  performed  at  other  than  O  or  I  level? 

c.  Can  the  function  be  performed? 


Answers  to  these  questions  might  consist  of: 

a.  That  function  is  only  for  Depot  level. 

b.  It  is  not  applicable  to  that  item. 

c.  Support  equipment  or  spares  are  not  available  in  the  field  to  do  that 
maintenance  function. 

d.  The  intended  user  is  not  trained  to  perform  that  function. 

7.5.3  Validation  of  Support  Equipment  Guide.  The  contractor  should  demonstrate 
at  validation  that  the  Support  Equipment  Guide  meets  the  following  requirements: 

a.  The  format  and  content  of  the  guide  are  in  accordance  with  the  speci¬ 
fication. 

b.  The  test  equipment,  tools,  and  ground  support  equipment  listed  in  the 
guide  are  those  that  have  been  approved  for  use  by  the  Acquisition  agency  for 
O  &  I  maintenance. 

c.  The  test  equipment  functions  and  standard  statements  which  are  included 
accurately  reflect  the  user’s  expected  capabilities,  as  defined  in  the  Definitized 
User  Profile. 

7.5.4  Validation  of  the  Task  Analysis  Worksheets.  The  contractor  must  show 
that  the  task  analysis  worksheets  prepared  for  each  task  satisfy  the  following 
requirements; 

a.  That  entries  are  complete  and  accurate  by  checking  all  data  on  the  sys¬ 
tem  hardware.  All  tasks  and  task  steps  must  be  validated  100  percent  on  the 
equipment.  Where  performing  tasks  and  task  steps  would  damage  or  degrade 
the  equipment,  simulated  performance  may  be  used,  if  approved  by  the  Acqui¬ 
sition  agency.  To  simulate  performance,  the  reviewer  validates  the  order  and 
content  of  procedural  steps  by  "walking  through"  worksheet  details  as  written. 
For  example,  to  perform  a  test  setup,  the  reviewer  checks  that  meter  settings 
can  be  accomplished  and  that  operating  controls  are  located  as  indicated,  with¬ 
out  actually  performing  the  operations. 

b.  That  appropriate  warnings,  notes,  cautions,  and  other  safety  hazards 
are  identified. 

c.  That  the  worksheet  has  sufficient  detail  (neither  too  much  ncr  too  little) 
to  provide  a  JPA  developer  with  full  detail  as  required  by  the  specification.  The 
validation  team  should  add,  delete,  or  modify  the  task  worksheet  details  as  such 
deficiencies  are  found  during  validation. 

d.  That  tolerance  ranges  for  performance  parameters  are  checked  and, 
if  Incorrect,  determined  empirically  at  each  point  of  test. 
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7.5.5  Validation  of  Action  Trees.  The  contractor  shall  validate  all  Action  Trees 
to  ensure  that  their  functional  organization  of  equipment  is  correct,  that  the 
troubleshooting  strategy  is  complete  and  logical,  and  that  procedural  informa¬ 
tion  is  validated  100  percent.  The  contractor  should  ensure  that  ATs  satisfy 
the  followii^  requirements: 

a.  That  they  reflect  the  use  of  authorized  test  equipment  and  tools. 

b.  That  their  testing  locations  were  selected  in  a  logical  manner,  consistent 
with  the  specification  guidelines  and  the  functional  organization  of  the  equipment. 

c.  That  half-split  strategy  requirements  are  properly  followed. 

d.  That  a  separate  Action  Tree  exists  for  every  fault  symptom  identified 
in  the  Fault  S3rmptom  List  and  that  the  AT  steps  expose  every  component  that 
can  produce  the  fault  ssmiptom. 

e.  That  the  Action  Trees  for  procedures  are  checked  100  percent  for  accu¬ 
racy,  adequacy,  and  performability,  that  the  sequence  of  task  steps  is  appropri¬ 
ate,  and  that  injected  faults  do  not  degrade  the  equipment  operation  and  thus 
ensure  that  the  ATs  are  capable  of  rapid  and  accurate  fault  diagnosis. 

f.  Validation  shall  establish  that  every  component  failure  mode  found  by 
an  AT  produces  the  symptom  for  which  the  AT  was  written,  and  that  the  AT  logic 
isolates  the  component.  This  validation  shall  be  accomplished  empirically  by 
actual  physical  simulation  of  each  component  failure  mode.  This  can  be  accom¬ 
plished  by  developing  "bvigged”  components  such  as  assemblies  with  known  mal¬ 
functioning  parts,  printed  circuit  modules  with  faulty  components,  adjusting 
voltages  or  mechanical  alignments  to  out-of-tolerance  levels,  operating  the 
system  in  a  degraded  condition,  etc. 

g.  An  AT,  or  part  of  an  AT,  need  not  be  completely  validated  if  it  can  be 
demonstrated  that  it  is  identical  to  an  AT  or  part  thereof  that  has  alreafy  been 
validated.  In  such  a  case,  failure  modes  shall  be  simulated  only  to  the  extent 
necessaty  to  determine  that  the  symptom  produced  is  the  one  for  which  that  AT 
was  written. 

h.  The  contractor,  in  the  process  of  validating  the  logic  of  each  AT,  shall 
also  determine  the  tolerance  range  of  all  Eqjplication-specific  readings.  These 
tolerance  ranges  shall  be  established  by  simulating  the  failure  mode  in  such  a 
way  that  the  entire  range  of  failure  (e.g. ,  range  of  hydraulic  pressure  or  range 
of  resistance  values )  can  be  observed  and  the  points  in  the  range  can  be  noted 
at  which  the  symptom  appears. 

i.  Malfunctions  that  would  tend  to  produce  power  supply  overload  need  not 
be  simulated  beyond  the  point  at  which  they  would  produce  the  full  rated  load  for 
the  supply  (as  measured  by  a  d3^amometer,  ammeter,  etc.). 
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j.  The  contractor  must  be  able  to  demonstrate  during  validation  that  each 
AT  has  a  corrective  action  (e.g.,  repair  or  replace)  for  every  component  listed 
as  a  possible  cause  of  the  fault  sjrmptom  for  which  the  AT  was  developed. 

7.5.6  Personnel.  The  personnel  who  participate  at  all  validation  proceedings 
should  include: 

a.  A  contractor  technical  authority  (or  subject  matter  expert)  who  can 
attest  to  the  technical  accuracy  of  MTI&A  products  and  their  appropriateness  to 
maintenance  philosophy,  test  equipment,  provisioning  philosophy,  etc. 

b.  A  contractor  quality  assurance  representative  who  is  empowered  to 
ensure  that  the  validation  is  performed  to  the  letter  of  contractual  specification. 

c.  A  government  witness,  at  the  option  of  the  Acquisition  agency. 

Full  or  part-time  attendance  is  also  recommended  for  the  following: 

d.  Task  analysts  who  developed  the  MTI&A  products. 

e.  A  "subject"  to  perform  procedures  who  possesses  training  and  tech¬ 
nical  capability  similar  to  the  intended  government  user-technician. 

f.  Contractor  management  personnel. 

7.5.7  Schedule.  The  contractor  should  schedule  the  formal  validation  process 
well  in  advance  of  contractual  deliveiy  requirements  so  that  there  is  ample  time 
for  procedural  revisions,  corrections,  and  access  to  the  equipment  for  revalida¬ 
tion,  if  necessary. 

7.5.8  Validation  Certificates.  After  MTI&A  products  have  been  validated,  the 
Validation  Certificates  should  uv?  forwarded  to  the  contracting  officer.  QA  per¬ 
sonnel  should  make  certain  that  all  corrections,  improvements,  or  additions 
are  quickly  satisfied  in  the  preliminary  products  and  are  revalidated  if  data  have 
been  changed  or  added. 

7.6  Verification.  The  contract  may  reqmre  contractor  task  analysts  or  technical 
personnel  to  participate  in  the  government  verification.  Even  if  the  contract  does 
not  include  this  requirement,  it  is  in  the  contractor's  best  interest  to  send  a  staff 
member  who  is  familiar  with  the  MTI&A  products.  The  contractor  can  usually 
reduce  the  number  of  comments  by  being  present  to  explain  why  certain  approaches 
were  taken.  Where  discrepancies  are  found  during  verification,  changes  or  cor¬ 
rections  can  be  prescribed  that  will  obviate  formal,  time-consuming  correspon¬ 
dence  which  often  includes  a  typed  set  of  comments,  some  of  which  the  contractor 
might  otherwise  have  to  respond  to  with  formal  documentation. 
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DEPARTMENT  OF  THE  AIR  FORCE 
I  FOMCC  HUMAN  MESOURCES  LABORATORV  (AFSC) 
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ival  of  Export  Control  Statement 


nse  Technical  Information  Center 
i:  DTIC/DOA  (Mrs  Crumbacker) 
ron  Station 
landria  VA  22314 


Please  remove  the  Export  Control  Statement  which  erroneously  appears  on 
Notice  Page  of  the  reports  listed  rnmltmmttSlSlKKUm.  This  statement  is 
■nded  for  application  to  Statement  B  reports  only. 

Please  direct  any  Questions  to  AFHRL/TSR,  AUTOVON  240-3877. 
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ELL  L.  ANDERSON,  Lt  Col,  USAF 
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